做企业级项目的朋友，应该都遇到过这类场景：

系统要对接的，不是我们设计的库，而是客户用了很多年的老业务库。

这类项目有两个绕不开的坎：

• 老库里表和字段的注释早就维护好了，可连进开发工具一看——注释全丢了，只剩下一排排看不懂的字段名；
• 客户数据库的版本或类型不在支持范围内，项目还没开工，先要花大把时间处理兼容性。

活字格12.1这轮数据库更新，正好就是冲着这两个问题去的。

一共四个动作，我们逐个看。

01 老库对接：注释终于不丢了，开发不用再"考古"

先聊最扎心的一个。

很多企业的数据库都是多年积累下来的，表名、字段名未必直观——T_STUDENT_INFO、HWMC、BZ……真正能说明业务含义的，往往是数据库里一条条早就配置好的注释。

但在过去，外联库连进设计器后，表和字段的注释并不会被带过来。开发人员眼前只有字段名和数据类型。

这意味着什么？

等于给你一本只有目录、没有正文的书。字段背后到底是什么业务含义，只能靠猜：翻旧文档、问老同事、对着历史代码反推。

12.1 的解决方式非常直接：连接外联库时，勾选【导入外联表的表注释和列注释】即可。

勾上之后，表注释、字段注释会跟着表结构一起进到设计器里。字段是干嘛的、什么业务含义，一眼就能看到。

这个功能看起来细，但对存量项目是真刚需。 省掉的不只是来回翻文档的时间，更是"猜错业务含义、返工重做"的隐性成本。

一句话：字段名是给机器看的，注释才是给人看的。以前人只能迁就机器，现在机器把人的语言还回来了。

02 兼容扩容：MySQL 9.7 和瀚高数据库，都安排上了

第二个问题，是数据库版本和类型的支持范围。

先看版本：新增支持 MySQL 9.7。

别小看这一条。客户的生产环境一旦用了新版本 MySQL，连接层支不支持，直接决定项目前期要花多少时间做版本适配、环境沟通。现在支持范围明确覆盖到 9.7，已经用上这个版本的客户，数据库连接这块就少了一桩心事。

再看类型：新增支持瀚高数据库。

这两年国产化、信创项目越来越多，一个很现实的情况是：客户的数据库选型早就定了，平台得去适配客户的环境，而不是让客户为了一个应用去换数据库。

瀚高数据库进入支持范围后，连接方式跟其他数据库一致——装好对应的数据库插件，在设计器里直接选。填写服务器名称、用户名、密码、数据库名、端口号（默认 5866）即可完成连接。

客户原有的数据表和业务数据继续作为系统底座，活字格负责把业务页面和应用功能搭起来。

新库能用、老库能接，这才是一个平台该有的数据库生态。

03 UserService 支持 PostgreSQL / 达梦：国产化"最后一公里"补齐了

前面三点说的是业务库的连接支持。最后补充一个容易被忽略、但信创项目里分量很重的点——管理控制台的 UserService 数据库。

UserService 数据库是干嘛的？

它保存的是活字格平台的用户、组织机构、角色权限这些基础数据。说白了，是整个系统的"户口本"。

在国产化交付中，很多项目业务库已经跑在国产数据库上了，但平台的用户权限库选项受限，等于"身体国产化了，户口还挂在别处"，交付时总有些别扭。

12.1 之后，管理控制台可以选择 PostgreSQL 或达梦数据库（DaMeng） 作为 UserService 数据库。

这意味着什么？

从业务数据到平台自身的用户权限数据，整条链路都可以跑在 PostgreSQL 或国产数据库上。 对于有信创要求、或者希望整体去商业化数据库依赖的项目来说，这算是把最后一块拼图补上了。

结语：四个动作，治的是存量项目的两类"慢性病"

把这次数据库更新汇总成一张表：

如果你正在做或准备做下面这类项目，这轮更新值得重点关注：

• 对接客户现有的老业务库（ERP、OA、自研系统）；
• 客户数据库版本较新，需要明确的支持承诺；
• 信创、国产化项目，数据库选型为瀚高、达梦；
• 需要整体去商业化数据库依赖的交付场景。

企业级低代码的数据库能力，不在于支持多少种炫酷的新技术，而在于接得住客户那些"已经跑了十年、还会再跑十年"的库。