如何管理SQL源代碼？

我負責數據庫。它有大約126個sprocs，大約20個視圖，一些UDF。有一些表格可以爲我們的各種應用程序保存固定的配置數據。如何管理SQL源代碼？

我一直在使用包含IF EXIST ... DELETE GO CREATE PROCEDURE ...的一個大文本文件...用於配置腳本的所有sprocs，udfs，視圖和所有插入/更新。

隨着時間的推移，新的sprocs被添加，或現有的sprocs被改變。

最大的錯誤（據我所知）我在創建這個BIG單個文本文件時所做的是在文本文件的開頭使用新/更改的sprocs代碼。但是，我忘了排除以前的新代碼/更改的sprocs代碼。讓我們說明這一點：

說我的大腳本（1版）包含的腳本來創建存儲過程

sp 1 
sp 2 
sp 3 
view 1 
view 2

的DATABSE的版本表獲取與版本更新1.

現在有在SP的某些變化2.因此，最大的腳本的版本2現在是：

sp2 --> (newly added) 
sp1 
sp2 
sp3 
view 1 
view 2

所以，很顯然運行BIG腳本版本2將不會更新我的SP 2

我很晚才意識到這與100多個sprocs。

補救措施：

我創建了一個文件夾結構。每個sproc/view的一個子文件夾。
我已經瀏覽了bgeinning的BIG腳本的最新版本，並將所有腳本的代碼放到了相應的文件夾中。一些腳本在BIG腳本中不止一次地重複。如果有多於一個代碼塊用於創建特定的存儲過程，我會將該早期版本放入另一個稱爲「舊」的子文件夾中。幸運的是，我總是記錄了我對所有sprocs/view等所做的所有更改 - 我記下了日期，版本號以及作爲備註存儲在代碼中的更改的描述。當存在多個代碼塊時，這幫助我瞭解了sprocs的最新版本代碼。
我創建了一個DOS批處理過程來連接所有單獨的腳本來創建我的BIG腳本。我曾嘗試使用.net streamreader/writer與編碼和「£」符號混淆。所以我暫時堅持DOS批處理。

有什麼辦法可以改善整個過程嗎？目前，我正在通過某種方式記錄BIG腳本的版本以及其各個sproc版本。例如，我喜歡有一些文件的方式

Big Script (version 1) contains 
sp 1 version 1 
sp 2 version 1 
sp 3 version 3 
view 1 version 1 
view version 1 

Big script (version 2) has 
sp 1 version 1 
sp 2 version 2 
sp 3 version 3 
view 1 version 1 
view 2 version 1

歡迎任何反饋意見。

來源

2009-02-21 ahmjt

你爲什麼還要繼續與大腳本鬥爭？使用Big Script創建什麼價值？爲什麼大腳本如此重要？請更新您的問題，爲大腳本提供一些理由。 – 2009-02-22 19:53:03

當我開始時，我有一個BIG腳本和數據庫。該公司正在爲最新的客戶提供最新的數據庫，以及BIG腳本來讓客戶更新他們的舊數據庫。如果有更好的方法來幫助我擺脫這個BIG腳本，我肯定會這樣做。 – ahmjt 2009-02-25 22:55:46

你看着Visual Studio Team System Database Edition（現在摺疊成開發版）？

它會做的一件事是允許維護SQL來構建整個數據庫，然後僅應用更改以將目標更新爲新狀態。我相信，在給定參考數據庫的情況下，它還會創建一個腳本，以使數據庫與參考模式匹配直至當前模型（例如，在沒有開發人員訪問產品的情況下部署到生產環境）。

來源

2009-02-21 12:10:58 Richard

我們這樣做的方式是爲表，存儲過程，視圖等分開文件，並將它們存儲在自己的目錄中。爲了執行，我們只需要一個執行所有文件的腳本。它比一個巨大的文件更容易閱讀。

要更新例如每個表中，我們使用這個模板：

if not exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[MyTable]') and OBJECTPROPERTY(id, N'IsUserTable') = 1) 
begin 

    CREATE TABLE [dbo].[MyTable](
     [ID] [int] NOT NULL , 
     [Name] [varchar](255) NULL 
    ) ON [PRIMARY] 

end else begin 

    -- MyTable.Name 
    IF (SELECT COL_LENGTH('MyTable','Name')) IS NULL BEGIN 
     ALTER TABLE MyTable ADD [Name] [varchar](255) NULL 
     PRINT 'MyTable.Name CREATED.' 
    END 

    --etc 

end

來源

2009-02-21 12:10:09

我猜，用來執行所有文件的腳本要求您在安裝過程中提供完整的文件夾結構。如果客戶端需要數據庫升級，您是否將腳本和文件夾結構發送給他們？我們使用if exists ... from information.schema.tables/routines BTW。 – ahmjt 2009-02-21 12:32:01

如何對要執行的文件的順序進行排序，尤其是在外鍵約束和SP依賴於不同表的情況下。 – Joe 2009-02-21 17:57:29

當我不得不處理SQL表，過程極少數，並觸發我做了以下內容：

所有文件版本控制（CVS在那個時候，但看SVN或集市爲例）每個對象
一個文件對象
一個makefile陳述DEPE得名文件之間的差異

這是一個oracle項目，每次更改表格時都必須重新引發其觸發器。而我的觸發器使用了幾個模塊，因此當它們的相關模塊更新時也必須重新編譯...

makefile避免了「大文件」方法：您不必爲每次更改都執行所有代碼。

在窗口中，您可以下載「NMAKE.EXE」使用的makefile

HTH

來源

2009-02-21 12:10:39 siukurnin

-1

請參閱我的回答類似的問題，這可能有助於：

Database schema updates

一些附加分：

當我們做一個版本，例如對於版本2，我們將修改日期的所有Sprocs連接在一起，這些日期比以前的版本更新。

我們注意在每個Sproc腳本的底部添加至少一個空行，並且用註釋啓動每個Sproc腳本 - 否則連接可能會產生「GOCREATE NextSproc」 - 這是一個缺陷！

當我們運行連接腳本時，我們有時會發現我們發生衝突 - 例如，調用不存在的子Sprocs。我們在腳本的底部複製這些Sprocs的代碼 - 以便第二次重新創建它們以確保SQL Server的依賴關係表是正確的。（即我們在發佈的QA階段對此進行分類）

另外，我們在每個Sproc腳本的底部放置了一個GRANT權限語句，以便在我們刪除/創建SProc時重新授予權限。但是，如果您的權限分配給每個用戶，或者在每個服務器上分配的權限不同，那麼最好使用ALTER而不是CREATE - 但如果SProc尚不存在，則會出現問題，因此最好請執行以下操作：

IF NOT EXIST ... 
    CREATE PROCEDURE MySproc AS SELECT 'STUB' 
    GRANT EXECUTE Permissions

然後該Stub立即被真正的ALTER Sproc語句替換。

來源

2009-02-21 13:15:22 Kristen

如何管理SQL源代碼？

回答

相關問題