RobinNotes

 在 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_SalesOr...