SQL Server業務規則的鏈接技術之探討
以下的文章主要描述的是關于SQL Server業務規則的鏈接技術的探討，關于這個問題一直存在一個的爭論，即在哪里存儲應用程序的相關業務邏輯的，到底是在應用程序本身的業務邏輯層中還是在數據庫層中。
應用程序邏輯層的絕對支持者提出，數據庫的唯一目的就是保存數據，以備應用程序所用。
提倡用數據庫來存儲SQL Server業務規則的人則堅持認為，業務規則最好存儲在數據庫中，因為數據也存儲在那里，規則在那里更容易運行。而在我看來，對于存儲應用程序的邏輯來說，沒有一個“最好的地方”——它真正取決于您正在解決的業務問題。
鏈接數據庫存儲過程
如果您更喜歡將全部或一部分業務邏輯存儲在數據庫中的話，那么知道SQL Server中的一種被我稱作業務規則鏈接的技術是很有好處的。基本思想就是您可以在數據庫中運行一系列的存儲過程，這是以在您需要的時候，不同進程的元數據存儲在一個數據庫表格中為基礎的。這樣做的好處就是，規則都存儲在數據庫的程序中，并且因為存儲過程的運行是以一個表格中的值為基礎的，所以您可以改變程序執行的順序，還能夠很容易地打開或終止SQL Server業務規則。讓我們來看一個例子，這樣概念會更清晰。
業務規則鏈接實例
要用我想用的方式在數據庫中執行SQL Server業務規則，就必須定義元數據。下面這些信息將會以數據庫表格的形式被保存：存儲過程的名稱、業務規則運行的順序、所運行業務程序的類型和業務規則是否活動等。列表A中包括了創建表格的腳本。
列表A：
- CREATE TABLE BusinessLogic ( ProcessType VARCHAR(20) NOT NULL,
- RunSequence TINYINT NOT NULL, LogicProcedure VARCHAR(255) NOT NULL,
- BusinessLogicActive BIT DEFAULT(1) NOT NULL,
- CONSTRAINT pk_BusinessLogic PRIMARY KEY (ProcessType, RunSequence) )
在列表B中，我在BusinessLogic表中加載了數據。這些數據是稍后我將用來處理業務規則的。RunSequence是執行存儲過程的實際順序（過程被存儲在LogicProcedure字段中）。表格中還包含了一個指示符，用來表示業務規則是否為活動的。
存儲這個數據讓我能夠改變規則運行的順序，或者在需要的時候打開或終止規則，而無需對代碼做出更改。要向業務邏輯系統中添加規則也十分簡單，因為所需做的就是向數據庫中添加程序，然后在元數據表格中添加需要的數據就可以了。
在列表C中，我創建了SQL Server業務規則程序（例子中包含的程序是非常簡單的；但是，在現實情況中，如果需要的話，它們可以很復雜）。所有的程序中包括了相同的輸入參數；這是業務規則鏈接的一個小小的局限性。
列表B：
- INSERT INTO BusinessLogic(ProcessType, RunSequence,
- LogicProcedure) VALUES('CustomerOrders', 1, 'usp_Rule1')
- INSERT INTO BusinessLogic(ProcessType, RunSequence,
- LogicProcedure) VALUES('CustomerOrders', 2, 'usp_Rule2') INSERT INTO BusinessLogic
- (ProcessType, RunSequence, LogicProcedure) VALUES('CustomerOrders', 3, 'usp_Rule3')
- INSERT INTO BusinessLogic(ProcessType, RunSequence, LogicProcedure) VALUES('CustomerOrders', 4, 'usp_Rule4')
列表C：
- CREATE PROCEDURE usp_Rule1 (@RunSequence TINYINT) AS PRINT 'In Procedure:
- ' + OBJECT_NAME(@@PROCID) PRINT 'Parameter Value Passed In:'
- + CAST(@RunSequenceAS VARCHAR(2)) GO CREATE PROCEDURE usp_Rule2
- (@RunSequence TINYINT) AS PRINT 'In Procedure: ' + OBJECT_NAME(@@PROCID)
- PRINT 'Parameter Value Passed In:' + CAST(@RunSequenceAS VARCHAR(2))
- GO CREATE PROCEDURE usp_Rule3 (@RunSequence TINYINT) AS PRINT 'In Procedure:
- ' + OBJECT_NAME(@@PROCID) PRINT 'Parameter Value Passed In:'
- + CAST(@RunSequenceAS VARCHAR(2)) GO CREATE PROCEDURE usp_Rule4 (@RunSequence TINYINT)
- AS PRINT 'In Procedure: ' + OBJECT_NAME(@@PROCID) PRINT 'Parameter Value Passed In:' + CAST(@RunSequenceAS VARCHAR(2)) GO
接下來就是處理SQL Server業務規則的代碼了。在列表D中，我用一個指針在表格中迭代，該表格中的記錄都保存著元數據。當可以用一種不同的循環結構來完成同一個邏輯時，用指針要簡單一些。不管是怎么樣完成的，都需要用某種類型的迭代循環和執行所需要的業務程序。運行這個代碼將執行每一個文章前面所定義的四個存儲過程。
列表D：
- DECLARE @LogicProcedure VARCHAR(255) DECLARE @RunSequence TINYINT
- DECLARE LogicCursor CURSOR FOR SELECT LogicProcedure, RunSequence
- FROM BusinessLogic WHERE ProcessType = 'CustomerOrders' AND BusinessLogicActive = 1
- ORDER BY RunSequence ASC OPEN LogicCursor FETCH NEXT FROM LogicCursor INTO
- @LogicProcedure, @RunSequence WHILE @@FETCH_STATUS = 0
- BEGIN EXECUTE @LogicProcedure --//Call procedure stored in variable
- @RunSequence = @RunSequence --//Pass in parameter PRINT '-----------------------------'
- FETCH NEXT FROM LogicCursor INTO @LogicProcedure, @RunSequence END CLOSE LogicCursor DEALLOCATE LogicCursor GO
在列表D中，有兩個主要引人注意的地方。第一個就是用來從表格中檢索記錄的select語句，所檢索的記錄中包含了處理業務規則的信息。從這個簡單的查詢中，我可以為任何類型的業務處理從BusinessLogic表中返回行。我還能保證規則是活動的，并且按照它們需要執行的順序返回。
第二個就是執行業務規則的方式。當指針迭代時，它從BusinessLogic表中檢索將要被執行的存儲過程的名稱，然后將其儲存在一個邏輯變量中。EXECUTE命令允許用戶執行存儲過程，即使該存儲過程的名稱被儲存在一個變量中。在這種方式下，調用存儲過程還使得我能夠向存儲過程中輸入所需的參數。
這使我回到了先前關于業務程序具有相同數量的輸入參數這一點。我能夠以一種相當動態的方式運行業務程序，這取決于在程序運行時BusinessLogic表中儲存了什么。但是，現在我還沒有一種方法可以動態地向業務程序輸入參數。
一種簡單的解決辦法就是保證所有的業務程序接受相同數量的參數，不管用不用它們。這種技術保證我們始終為業務程序提供所需的參數。也有其他的方法可以實現這些所需參數的輸入，但是那些不是這篇文章所要討論的。
扼要重述
如果您的應用程序在數據庫中儲存它的任何一個或全部業務邏輯，那么有可能它就是被我稱作SQL Server業務規則鏈接的一個候選者。這種方法允許存儲過程在數據庫中依次運行，并且讓您能夠在需要的時候打開或終止這些業務規則。
使用這種方法的一些潛在缺陷包括數據安全（執行業務程序的數據儲存在一個表格中），和向業務邏輯程序輸入參數的非動態性。如果您覺得對于您的業務問題來說，這種方法利大于弊的話，我鼓勵您嘗試一下這種方法。
【編輯推薦】
- SQL Server 分布式數據庫的2種不同系統
- 造成SQL Server查詢速度慢的10種原因
- 造成SQL Server查詢速度慢的原因與優化
- 三種SQL Server 恢復模式的比較
- 對SQL Server 2008的商業智能的解析
