SQL Server 2008中的業務邏輯

Question

如果那里有DBA，我正在制作相當大的軟件，而目前最大的問題之一就是將業務邏輯放在何處。 盡管存儲過程更容易即時修復，但處理要求可能會極大地降低數據庫的速度。 我也不想讓應用程序處理所有業務邏輯，因為我希望它是一個不需要用戶前端即可操作的“自我維持的實體”。

我的想法是創建一個在某處的中央服務器上運行的服務，並使客戶端通過該服務器連接。 該服務將維護所有業務邏輯，並充當所有數據庫操作的前端。

有想法嗎？ 是？ 沒有？

我願意接受我也缺少一些關鍵概念，需要閱讀一些文獻。

Answer 1

我建議您密切注意您認為的業務邏輯與參照完整性約束之間的區別。

確保使數據有意義地相關的所有約束在數據庫層均已到位。 例如，如果您需要級聯一些刪除或插入操作，並且需要驗證一些基本數據值以使所有內容有意義，那么這些都應該位於數據庫中。

然后確定客戶端，中間層服務器或數據庫是否適合任何其他業務邏輯。

Answer 2

您所說的“業務邏輯”是什么意思？

我已經看到了在客戶端代碼中完成了聚合和其他基於集合的操作的情況，以及在SQL中應有的可怕的RBAR操作。

SQL是擁有它的一種工具：如果您正在處理大型數據集，JOIN，聚合等，那么SQL就是這樣做的地方。 任何其他事情都是對SOA理想的奴役。

我的方法是考慮存儲的proc或SQL在做什么：它是中間層的一部分，以避免在過程代碼中進行基於集合的操作，還是因為純數據完整性/持久性較低？

如果您的業務邏輯是基於100％設置的，那么您可以說不需要中間層（編輯：基於客戶端代碼），除非它很薄。

Answer 3

多年來，我已經看到客戶端應用程序來來往往，但是數據庫仍然存在。

因此，如今，我將存儲過程用於大多數業務邏輯。 三大優勢：

• 漏洞修復部署只需瞬間，無需停機
• 默認為多用戶
• 更少的管道代碼（無數據訪問層）

Answer 4

在服務器端擁有所有業務邏輯都很好。
在服務器端不使用它也可以。

實際上，這取決於您。
如果存儲過程看起來不像sql-ish，則可以創建CLR存儲過程 。

這是一個類似的問題 。

Answer 5

我強烈建議使用傳統的n層方法，其中至少要具有UI層，業務層（例如C＃程序集或Java等價物）和數據訪問權限。 請參閱： http : //en.wikipedia.org/wiki/Multitier_architecture 。

我在一家公司中工作，所有業務邏輯都在proc中，並且維護成本比必須的要高得多，它使我們限於特定版本的sql server，無法擴展，等等。總之，除非您的應用程序是一件簡單的事情，我不會在數據庫中放入任何業務邏輯。