AI辅助数据库设计评审

场景

我们之前已经基于之前大模型同一会话进行过需求评审，在研发设计完成数据模型后，导出数据库设计DDL文件，上传到AI平台进行下一步评审。

实践

groupbuy.txt文件是我们数据库设计SQL脚本文件

提示词1

您是软件工程专家，我刚刚上传 数据库设计DDL 文件 {groupbuy.txt}，请结合以上需求与原型，对数据库表结构设计进行评审反馈建议，参考： 数据模型评审 {实体完整性：检查是否所有实体都已正确定义，并且主键和外键关系正确无误。属性完整性：确保每个属性的数据类型、长度和约束（如非空、唯一性）都符合业务需求。关系完整性：检查实体之间的关系是否正确，包括一对一、一对多、多对多关系}

通义千问

这些建议还是比较中肯

提示词2

您是数据库设计专家，请按我提供 《MySQL数据库设计规范》，结合以上功能列表，需求描述与原型 对文件{groupbuy.txt} 中的数据库设计再次进行评审：

MySQL数据库设计规范

{以下所有规范会按照【高危】、【强制】、【建议】三个级别进行标注，遵守优先级从高到低。对于不满足【高危】和【强制】两个级别的设计，DBA将强制打回要求修改。

1.一般命名规则

【强制】使用小写，有助于提高打字速度，避免因大小写敏感而导致的错误。

【强制】没有空格，使用下划线代替。

【强制】名称中没有数字，只有英文字母。

【强制】有效的可理解的名称。

【强制】名称应该是自我解释的。

【强制】名称不应超过 32 个字符。

2.库命名

【强制】使用单数。

【强制】库的名称格式：业务系统名称_子系统名。

【强制】一般分库名称命名格式是库通配名_编号，编号从 0 开始递增，比如 northwind_001，以时间进行分库的名称格式是库通配名_时间。

【强制】创建数据库时必须显式指定字符集，并且字符集只能是 utf8 或者 utf8mb4。

3.表命名

【强制】使用单数。

【强制】相关模块的表名与表名之间尽量体现 join 的关系，如 user 表和 user_login 表。

【强制】创建表时必须显式指定字符集为 utf8 或 utf8mb4。

【强制】创建表时必须显式指定表存储引擎类型，如无特殊需求，一律为 InnoDB。当需要使用除 InnoDB/MyISAM/Memory 以外的存储引擎时，必须通过 DBA 审核才能在生产环境中使用。因为 InnoDB 表支持事务、行锁、宕机恢复、MVCC 等关系型数据库重要特性，为业界使用最多的 MySQL 存储引擎。而这是其它大多数存储引擎不具备的，因此首推 InnoDB。

【强制】建表必须有 comment。

【强制】关于主键：(1) 命名为 id，类型为 int 或 bigint，且为 auto_increment；(2) 标识表里每一行主体的字段不要设为主键，建议设为其它字段如 user_id，order_id等，并建立 unique key 索引。因为如果设为主键且主键值为随机插入，则会导致 InnoDB 内部 page 分裂和大量随机 I/O，性能下降。

【建议】核心表（如用户表，金钱相关的表）必须有行数据的创建时间字段 create_time 和最后更新时间字段 update_time，便于排查问题。

【建议】表中所有字段必须都是 NOT NULL 属性，业务可以根据需要定义 DEFAULT 值。因为使用 NULL 值会存在每一行都会占用额外存储空间、数据迁移容易出错、聚合函数计算结果偏差等问题。

【建议】建议对表里的 blob、text 等大字段，垂直拆分到其它表里，仅在需要读这些对象的时候才去 select。

【建议】反范式设计：把经常需要 join 查询的字段，在其它表里冗余一份。如 username 属性在 user_account，user_login_log 等表里冗余一份，减少 join 查询。

【强制】中间表用于保留中间结果集，名称必须以 tmp_ 开头。备份表用于备份或抓取源表快照，名称必须以 bak_ 开头。中间表和备份表定期清理。

【强制】对于超过 100W 行的大表进行 alter table，必须经过 DBA 审核，并在业务低峰期执行。因为 alter table 会产生表锁，期间阻塞对于该表的所有写入，对于业务可能会产生极大影响。

【强制】表达是与否概念的字段，必须使用 is_xxx 的方式命名，数据类型是 unsigned tinyint( 1 表示是，0 表示否)。说明 : 任何字段如果为非负数，必须是 unsigned。正例 : 表达逻辑删除的字段名 is_deleted，1 表示删除，0 表示未删除。

【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。正例 : getter_admin，task_config，level3_name反例 : GetterAdmin，taskConfig，level_3_name

强制】表名不使用复数名词。说明 : 表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DO 类名也是单数形式，符合表达习惯。

【强制】禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。

【强制】主键索引名为 pk_字段名；唯一索引名为 uk_字段名；普通索引名则为 idx_字段名。说明 : pk_ 即 primary key；uk_ 即 unique key；idx_ 即 index 的简称。

【强制】小数类型为 decimal，禁止使用 float 和 double。说明 : float 和 double 在存储的时候，存在精度损失的问题，很可能在值的比较时，得到不正确的结果。如果存储的数据范围超过 decimal 的范围，建议将数据拆成整数和小数分开存储。

【强制】如果存储的字符串长度几乎相等，使用 char 定长字符串类型。【强制】varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。

【建议】表的命名最好是加上“业务名称_表的作用”。正例 : tiger_task / tiger_reader / mpp_config

【建议】库名与应用名称尽量一致。

【建议】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。

【建议】字段允许适当冗余，以提高查询性能，但必须考虑数据一致。冗余字段应遵循: 1)不是频繁修改的字段。 2)不是 varchar 超长字段，更不能是 text 字段。正例 : 商品类目名称使用频率高，字段长度短，名称基本一成不变，可在相关联的表中冗余存 储类目名称，避免关联查询。

【建议】单表行数超过 500 万行或者单表容量超过 2GB，才推荐进行分库分表。说明 : 如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。

【建议】合适的字符存储长度，不但节约数据库表空间、节约索引存储，更重要的是提升检索速度。

4.字段命名

【建议】尽可能选择短的或一两个单词。

【强制】避免使用保留字作为字段名称：order，date，name 是数据库的保留字，避免使用它。可以为这些名称添加前缀使其易于理解，如 user_name，signup_date 等。

【强制】避免使用与表名相同的字段名，这会在编写查询时造成混淆。

【强制】在数据库模式上定义外键。

【强制】避免使用缩写或基于首字母缩写词的名称。

【强制】外键列必须具有表名及其主键，例如：blog_id 表示来自表博客的外键 id。}

通义千问

这些建议还是比较细致， 实际情况下，我们可以根据公司自己 数据库设计要求的规范，更新提示词中的规则。

ChatGPT4-o

进一步追问 数据库设计与需求功能一致性

您是DBA, 请评审上传 数据库设计{groupbuy.txt} 的关系模型 是否 符合 拼团分销功能清单.xlsx 文件中 需求一致，有哪儿些不足？

如果有PRD或SRS文档效果评审结果更准确

您是QA，请根据我上传的需求原型设计图片，结合需求功能列表，对于数据库设计文件{groupbuy.txt}再次评审，反馈技术评审报告

豆包

提示词

您是软件QA专家, 请评审上传 数据库设计{groupbuy.txt} 的关系模型 是否 符合 拼团分销功能清单.xlsx 文件, 理解原型设计图中业务需求，判断需求一致性，合理性，有哪儿些不足，输出数据库设计评审报告。

包含评审报告模板

您是软件QA专家, 请评审上传 数据库设计{groupbuy.txt} 的关系模型 是否 符合 拼团分销功能清单.xlsx 文件, 理解原型设计图中业务需求，判断需求与设计一致性，合理性，扩展性， 包含具体有哪儿些不足，输出数据库设计评审报告。

{软件数据库设计评审报告

一、背景

本报告旨在对软件数据库设计进行评审，确保数据库设计满足系统需求，结构合理，并具备可维护性、可扩展性、可靠性和安全性等特点。

二、评审内容

本次评审的数据库设计包括但不限于以下方面：

数据库环境说明

数据库的命名规则

逻辑设计

物理设计

安全性设计

优化

数据库管理与维护说明

三、评审标准

评审将依据以下标准进行：

正确性、完整性、一致性

安全性

“时－空”效率

四、评审结果

经过全面评审，得出以下结论：

数据库环境说明：[具体评审结果]

数据库命名规则：[具体评审结果]

逻辑设计：[具体评审结果]

物理设计：[具体评审结果]

安全性设计：[具体评审结果]

优化：[具体评审结果]

数据库管理与维护说明：[具体评审结果]

五、评审意见和建议

[具体建议和意见]

六、结论

[综合评审结果，得出的结论] }

自动化评审

基本思路是基本思路：

1）CI工具拉取GIT中PDM文件

2）生成SQL文件到临时目录

3）提交git commit

4）发起merge request

5）可提前准备好需求文档相关， 大模型对merge request的diff进行review

6）产出review结果到merge request评论中

7）评审人 辅助决策是否通过pass

可以参考的数据库设计规范

阿里JAVA开发手册

https://developer.aliyun.com/ebook/386

MySQL 数据库设计规范

https://github.com/guanguans/notes/blob/master/MySQL/MySQL%E6%95%B0%E6%8D%AE%E5%BA%93%E8%AE%BE%E8%AE%A1%E8%A7%84%E8%8C%83.md

总结

1. 提高评审效率：

• AI能够自动提取关键信息，快速生成评审报告，大大缩短了评审周期。
• AI还能通过实时监测和智能化建议，帮助评审人员更快地发现问题并作出决策。

2. 增强评审准确性：

• AI基于大数据和机器学习算法，能够更准确地分析数据库设计的优缺点，提供更有针对性的建议。
• AI还能通过比对和分析历史数据，发现潜在的缺陷和风险，提高评审的准确性。

3. 保障数据安全与隐私：

• AI通过对异常数据的分析和检测，可以及时发现潜在的安全隐患，提高数据的安全性。
• AI还能通过数据加密、访问控制等技术手段，保障数据的隐私性。

4. 推动数据库设计的创新与发展：

• AI的引入为数据库设计评审带来了新的思路和方法，推动了数据库设计的创新与发展。
• AI还能通过不断学习和优化，提高数据库设计的水平和质量。

So，基于AI辅助数据库设计评审的场景广泛且意义重大，它不仅提高了评审效率和准确性，还保障了数据的安全与隐私，推动了数据库设计的创新与发展。

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。