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輔助資料庫設計評審的場景廣泛且意義重大，它不僅提高了評審效率和準確性，還保障了資料的安全與隱私，推動了資料庫設計的創新與發展。

---

今天先到這兒，希望對雲原生，技術領導力， 企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管理，資訊保安，團隊建設 有參考作用 , 您可能感興趣的文章:
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
影片直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續整合/CD
網際網路電商購物車架構演變案例
網際網路業務場景下訊息佇列架構
網際網路高效研發團隊管理演進之一
訊息系統架構設計演進
網際網路電商搜尋架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
網際網路資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之效能實時度量系統演變

如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。 該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。