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這兩者優點的應用程式了。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/16436858/viewspace-622811/，如需轉載，請註明出處，否則將追究法律責任。