讓資料庫也進入 AI 開發流程：Visual Studio Database Project × Codex 的 ERP SQL Server 開發實務

 在 ERP 或企業級系統裡，SQL Server 很少只是「放資料的地方」。資料表當然在裡面，但真正決定系統怎麼運作的商業規則，常常躲在 View、Trigger、Stored Procedure、Function，還有跨資料表的檢核邏輯裡。系統跑得愈久，這些關係就愈盤根錯節。一個看起來不大的需求，最後可能牽動好幾張表、數支預存程序，甚至某個平常沒什麼人碰的 Trigger。

傳統作法多半是直接進 SQL Server 改物件，改完再把 SQL Script 留存下來。短期看起來很快，時間一久卻會出現一個尷尬的狀況：資料庫成了真正的最新版，原始碼反而只剩下修改紀錄。

AI Coding Agent 開始進入日常開發之後，我想把這個關係翻過來：讓 Database Project 成為資料庫結構與程式碼的唯一依據，Codex 只動專案裡的原始碼，最後由開發者看差異、決定要不要部署。對 Stored Procedure、Trigger 和商業邏輯比重都很高的 ERP 系統來說，這條界線特別重要。

第一步：先把 SQL Server 變成可以管理的專案

Visual Studio 的 SQL Server Database Project，可以把既有資料庫的 Schema 匯進一般專案結構。既有的 ERP 資料庫可以先匯入 Database Project，把資料庫物件轉成 .sql 原始碼，例如：

  • Tables
  • Views
  • Stored Procedures
  • Functions
  • Triggers
  • Schema
  • Index、Constraint 等結構定義

Microsoft 把 SQL Database Project 定義為「單一資料庫 Schema 中 SQL 物件的本機表示」。它用宣告式 T-SQL，每個物件都有自己的定義檔，要調整物件就直接改這份定義，而不是累積一串曾經手動執行過的 ALTER Script。這聽起來只是管理方式不同，但實際做過就會發現，資料庫從此開始有一般程式碼該有的可讀性和可追溯性。 參考：Microsoft Learn — What are SQL database projects?

例如原本資料庫中的：

text
dbo.ORDER_HEAD
dbo.ORDER_LINE
dbo.CreateProcess_SalesOrder
dbo.TR_ORDERHD_Update

匯入後都會變成 Database Project 裡可以搜尋、比較、放進版本控制的 SQL 原始碼。從這一刻起，AI 看到的不再只是使用者貼進提示詞裡的一小段 Stored Procedure，而是整個資料庫專案可以追查的上下文。

第二步：讓 Codex 直接工作在 Database Project

接下來只要把 Codex 的工作目錄指向 Visual Studio Database Project 所在的資料夾。OpenAI 的文件說明，Codex 可以在專案目錄中檢視檔案、分析程式碼、修改檔案並執行開發工具，不必再把 Stored Procedure 一段段複製到對話視窗。 參考：OpenAI Codex — Work against your local repository

為什麼不讓 Codex 直接連接 SQL Server？

為什麼不乾脆讓 Codex 直接連 SQL Server，需要什麼就即時查 Table Schema、Stored Procedure、Function、Trigger 和物件相依性？技術上做得到。但對 ERP 或企業級系統，我不會拿這個當預設模式。

一個原因是上下文成本。要理解一個大型 ERP 資料庫，Codex 得反覆查 Metadata 和物件定義，再把結果帶回來分析。資料庫裡若有數百、數千個物件，Schema 和 Procedure 反覆讀取，很快就會吃掉大量上下文。Database Project 已經把這些定義攤成原始碼檔案，Codex 可以先搜關鍵字和引用關係，只打開真正相關的檔案，路徑清楚很多。

另一個原因比較現實：存取風險。直接連線就得給資料庫的 Network Access 和 Credential，即使原本只想讀 Schema，只要帳號或工具同時有寫入權限，就得多防一層誤執行 DDL、DML，甚至碰到正式資料的可能。OpenAI 對 Codex 權限的說明也強調 Filesystem 和 Network Access 都該限縮在完成工作所需的最小範圍。 參考：OpenAI Docs — Permissions

所以我會將 Database Project 當成 Codex 與 SQL Server 之間的一層隔離。Codex 取得的是完整、可搜尋的資料庫程式碼，但不需要 SQL Server 帳號，也不用直接碰資料庫；分析和修改都停在 Source Code，真正的 Database Update 留到後面的人工 Review 和部署階段。

舉一個常見的 ERP 需求：訂單送出簽核時，如果送單者本身也是第一層簽核群組成員，就不能自己審自己的單；系統還得依 Workflow 規則判斷要不要加一層簽核。這種情況不必一開始就告訴 Codex「改哪一支 Stored Procedure」。比較好的做法，是先把商業需求和限制條件講清楚，讓它自己從 Database Project 追出來：

  1. 找出訂單簽核流程的入口 Stored Procedure。
  2. 搜尋 Workflow 定義資料表及欄位被哪些物件使用。
  3. 追蹤 Stored Procedure 之間的呼叫關係。
  4. 分析現有簽核邏輯與新需求的衝突點。
  5. 提出修改方案及可能受影響的範圍。
  6. 確認方案後，再修改需要變更的 .sql 檔案。

這跟叫 AI「幫我寫一段 SQL」差很多。它不再只是個 SQL 產生器，而是能讀既有系統、追相依關係，再依需求改程式碼的 Coding Agent。

第三步：把 AI 的能力留在原始碼層

這大概是整套流程裡我最堅持的一點。責任切成兩塊。

Codex 負責：

  • 閱讀 Database Project
  • 搜尋相關資料表、Trigger、Function、Stored Procedure
  • 分析程式邏輯與相依關係
  • 提出實作方案
  • 修改 SQL Project 中的原始碼
  • 協助檢查變更與潛在問題

Visual Studio 和開發者負責：

  • 檢視所有實際變更
  • Build Database Project
  • 比對 Project 與目標 Database
  • 檢查部署 SQL
  • 決定哪些變更可以部署
  • 將核准的 Schema 變更同步至 SQL Server

「Codex 只修改原始碼」不是能力不夠，是刻意畫出來的邊界。這讓 AI 產生的每一筆修改，都留在可以閱讀、可以 Diff、可以 Review、也可以回復的狀態——比起把 AI Coding Agent 直接接上 Production Database、讓它自己跑 DDL 或改資料，安心很多。

第四步：回到 Visual Studio 檢視 AI 做了什麼

Codex 做完，不代表需求已經套進資料庫了。回到 Visual Studio，Database Project 裡被改動的還只是原始碼。

搭配 Git，可以清楚看到哪些檔案被修改、哪些欄位新增或刪除、Stored Procedure 哪幾段邏輯被改寫、Trigger 有沒有動到，以及有沒有混進需求之外的變更。

接著 Build Database Project。SQL Project 的 Build 會驗證物件間的參照，還有目標 SQL 平台的語法，並產生 .dacpac 部署產物。這一道人工 Review 對長期維護的 ERP 而言不是走個形式：AI 可以負責產生修改，但這個修改究竟該不該進資料庫，還是得由懂業務、懂風險的人來判斷。

第五步：比較 Project 與 Database，再決定是否同步

最後用 Schema Compare 比對，Source 是 Database Project，Target 是開發或測試環境的 SQL Server Database。Visual Studio 會把兩邊的 Schema 差異列出來。Microsoft 也說明，Schema Compare 可以用來檢視 Database 與 Project 間的物件差異，選定的差異能套用到任一邊，也能產生實際部署用的 SQL Script。 參考：Microsoft Learn — Compare a database and a project

真正 Update 或 Publish 之前，這裡還能再確認一次：

  • 是否新增預期中的欄位
  • 是否只修改預期中的 Stored Procedure
  • 是否意外 Drop 物件
  • 是否造成 Table rebuild 或大量 Data Motion
  • 部署 Script 是否包含高風險操作

確認過了，才把變更同步到開發或測試資料庫，測完再依公司的發布流程進正式環境。整個流程大概長這樣：



Database Project 的價值不只是方便部署

如果只把 Database Project 當成另一種發布 SQL 的工具，其實低估了它。對 AI 輔助開發來說，它更重要的作用，是把資料庫程式變成一個 AI 能完整閱讀、理解、修改的 Codebase。

以前我們可能在 SSMS 裡找到一支 Stored Procedure，複製給 AI，改完貼回去。AI 只看得到局部，自然不知道同一個欄位是不是還被其他 Procedure、Function 或 Trigger 用著。整個 SQL Server Schema 都存在 Database Project 裡以後，Codex 就能從專案層級處理問題：搜引用、看相鄰物件、對照既有設計，再判斷真正該改哪些檔案。

這對 ERP 特別有用，因為 ERP 的需求很少只是單一 SQL 問題，往往橫跨資料結構、商業規則、簽核流程、庫存、成本、會計——一個地方調整，很容易在另一個地方留下後座力。

企業系統仍要守住的安全線

就算用了這套模式，Database Project 的 Publish 也不該當成無條件自動更新。以下這些變更還是得人工檢查：

  • Drop Table / Drop Column
  • 欄位型別或長度縮減
  • NOT NULL 欄位新增
  • 大型資料表的 Index 變更
  • 可能造成 Data Motion 的 Schema 修改
  • 需要搬移、轉換或修補既有資料的需求
  • Pre-Deployment / Post-Deployment Script

Schema 是宣告式的，但 ERP 的資料帶著歷史和業務意義。結構應該長成什麼樣子，跟既有資料怎麼安全走到新結構，其實是兩件事。

比較穩健的做法，是把需求交給 Codex 分析和開發，變更留在 Source Code；人員透過 Diff、Build、Schema Compare 和 Deployment Script Review，握住最後一道資料庫變更權。

結語

導入 Codex 之後，我反而覺得 SQL Server Database Project 比以前更有價值。它在 SQL Server 和 AI Coding Agent 之間，放進了一條清楚的路徑：

Database → Project → AI 修改 Source Code → Human Review → Database

這不是讓 AI 拿到更大的資料庫權限，反而是把它的能力收攏在更容易控制、更容易稽核的 Source Code 層。對長期維護的 ERP 或企業系統來說，重點從來不是讓 AI 多寫幾支 Stored Procedure，而是讓資料庫開發慢慢有一般軟體工程早就習慣的東西：版本控制、差異檢視、Code Review、可重現部署，還有清楚的變更責任邊界。

資料庫也成為 Code 之後，AI 才真正有機會參與企業系統完整而可控的開發流程。