SQL Server數據體系和應用程序邏輯

在許多用SQL Server實現的新的企業系統設計中，系統設計師需要在給數據結構和管理應用程序邏輯的定位上做出具有關鍵性意義的決定。SQL Server有它自己的編程語言(Transact-SQL，即TSQL)，開發者可以用它來管理數據訪問、代碼事務邏輯和交易控制。
　　使用TSQL，開發者可以創建保存過程，在保存過程中用一段可重用、預編譯而且擁有自己的許可設置的代碼塊來封裝數據訪問。數據庫中每個表格都有一組叫做triggers的特殊的保存過程。當底層數據庫發生特定的數據庫事件(如Insert、Delete或者Update)時，trigger就被 “觸發”了。使用triggers，開發者就可以編寫基於事件的事務邏輯，這樣，給定表格的Insert、Delete和Update事件就可以驅動其它表格的變化。
　　既然有了這樣的靈活性，那麼我們為什麼不盡可能用TSQL寫更多的事物邏輯呢?
　　使用TSQL來開發應用程序邏輯存儲
　　TSQL不僅可以作為單個應用程序的邏輯倉庫，它也可以是一個訪問相同數據的應用程序組的邏輯倉庫——這有幾個邏輯上的原因。通過對數據的集中處理和管理SQL server中數據的規則，你可以配置這樣的安全體系——即應用程序在通過事務規則之前，不可以訪問底層數據庫。
　　這是大多數兩層客戶——服務器應用程序的常見數據庫范例。該體系把所有的事務邏輯和數據訪問交給後端的服務器而把豐富的表示邏輯交給客戶端。客戶管理事務過程和數據的視(view)，但不在本地處理除顯示之外的其它事務。如果把所有的事務邏輯放到中央倉庫去，那麼這個體系還有降低管理成本的潛力，但這會付出降低了可測性的代價。
　　我最近接觸了一個客戶，它花了數百個人月(一個人工作一個月的工作量)和數以千計的美元來設計一個非常復雜的、用TSQL管理所有應用程序邏輯的應用程序。盡管該體系非常精巧、在10到15個用戶的情況下也運行良好，但是如果有20個用戶，速度就非常慢。通過給SQL server增加處理器的方法，該系統可以允許60個用戶同時使用。但是這距離100個用戶的設計目標還有很大一段距離，這就使得該公司在 Internet上開放該應用程序的計劃無法實施下去。由於存儲過程和trigger只能操作本地數據，該公司無法把該應用程序分解成多個SQL server以提高可測性。結果，該公司不得不大規模的修改它。
　　在應用程序邏輯中使用.NET類
　　上面那家公司在經過一段曲折後所發現的問題，大多數體系設計師在體系設計階段都會重新認識到——應用程序邏輯包含在一組.NET類的n層體系可以增加該應用程序的靈活性和可測性。由於TSQL是一種以管理數據為主要目的的語言，因此它不夠靈活，但是我們仍可以用TSQL編寫出復雜的事務邏輯。
　　如果開發者使用.NET框架，那麼他們可以在開發核心事務過程時做出自己的語言選擇。這個靈活性可以讓你對應用程序要求和開發語言或者資源進行最合理的搭配。而且如果適當開發，封住這些事務過程的對象可以在多台機器上運行並共享同樣的底層數據庫server。在與處理TSQL事務邏輯無關的情況下，SQL server可以應付大量的並發請求。
　　行操作(row operation)和集操作(set operations)
　　在規劃體系階段時判斷使用行操作還是集操作的一個指導思想就是：如果使用TSQL就使用集操作，如果使用.NET則進行行操作。通過網絡連接來提供大量的數據會影響應用程序的整體性能，所以只要有可能就使用server來處理它們——這樣做是很有意義的。但是從內存和處理能力的角度來看，SQL Server的指針(cursor)是非常昂貴的對象，因此創建一個指針來遍歷集合中的所有記錄並依次處理這些記錄一般來說並沒有多大意義。  (.)
　　當你需要執行基於行的處理，而這些處理包括了復雜的程序邏輯或者占用CPU比較厲害的操作時，你就應該從server中查詢這些行並在中間層來處理它們。
　　如果你想通過一個例子來看看如何把數據訪問邏輯封裝到一個中間層對象中去，請從MSDN中下載數據訪問應用程序模塊。這是一個提供代碼的、可重用的數據訪問子系統，你可以根據它來編寫自己的數據庫或者特性應用程序的數據訪問對象。
　　通過創建可重用的.NET應用程序框架來處理大多數應用程序邏輯、並用基於TSQL的保存過程來作為服務器端的集操作的安全限制和機制，那麼你就可以創建同時擁有TSQL和.NET這兩者優點的應用程序了。