如果有任何DBA出現，我正在製作一個相當大的軟件，目前最大的問題之一就是放置業務邏輯的位置。雖然存儲過程在實時更容易修復，但處理需求可能會大大減緩數據庫的速度。我也不想讓應用程序處理所有的業務邏輯，因爲我希望它成爲一個不需要用戶前端操作的「自我維持實體」。SQL Server 2008中的業務邏輯
我的想法是創建一個服務在某個中央服務器上運行，並讓客戶端通過它連接。該服務將維護所有業務邏輯並作爲所有數據庫操作的前端。
想法？是？沒有？
我願意接受我也缺少一些關鍵概念，需要閱讀一些文獻。
你是什麼意思的「業務邏輯」？
我見過在客戶端代碼中已經完成聚合和其他基於集合的操作的情況，以及SQL中可怕的RBAR操作應該在別的地方。 SQL是一個有它的地方的工具：如果你正在處理大型數據集，JOIN，聚集等，那麼SQL就是這樣做的地方。其他任何東西都是對SOA理想的奴隸服從。
我的方法是考慮存儲過程或SQL正在做什麼：它是否在過程代碼中避免基於集合的操作的中間層的一部分，還是低於純數據完整性/持久性？
如果您的業務邏輯是 100％基於設置，那麼您不需要中間層（編輯：基於客戶端代碼），除非它非常薄。
啊，提供一些信息。我會讓數據庫簡單地維護數據邏輯。就像，如果這個字段可以或不可以爲空，它將應用所述限制。如果刪除此記錄應該級聯到子記錄，它將處理該記錄。然而（對於一個凌亂的例子），如果我有拖欠付款，我可能要記錄其拖欠。這將由中間人應用程序完成。如果我的庫存中存在不一致的情況，那麼我會讓中間主要處理該問題。假設這就是你所指的。 – instantmusic 2010-08-09 17:55:17
@ instantmusic：是的。蘭迪的回答表明它比這個更好。拖欠付款只是在狀態字段（或其他內容）中具有不同值的付款，不能也不應該由SQL確定。但是，計算特定狀態的支付總和將爲：客戶端發送要處理的狀態。 – gbn 2010-08-09 18:00:03
正確的，所以我可以公開必要的存儲過程來提供有關數據狀態的信息。即sp_GetCustomerDelinquentTotal（Customer）只會返回單個客戶拖欠的總$$$。 – instantmusic 2010-08-09 18:02:22
擁有服務器端的所有業務邏輯都沒問題。
沒有它在服務器端也是好的。
事實上，這取決於你。
如果存儲過程往往看起來不是sql-ish，那麼可以製作一個CLR stored procedure。
邪惡，謝謝你的鏈接。 – instantmusic 2010-08-09 17:59:40
我強烈推薦一個傳統的n層方法，其中至少有UI層，業務層（如C＃程序集或Java equivolent）和數據訪問。參見：http://en.wikipedia.org/wiki/Multitier_architecture。
我在一家公司工作，所有的業務邏輯都在proc中，而且固定成本遠高於他們，它限制我們使用特定版本的sql server，它不具備可擴展性等。總之，除非你的應用程序是一個簡單的丟棄類的東西，否則我不會在數據庫中放置任何業務邏輯。
我建議您密切關注您認爲的業務邏輯與參照完整性約束之間的區別。
確保所有保持數據有意義相關的約束都在數據庫層。即如果您需要級聯一些刪除或插入 - 並且您需要驗證一些基本數據值以便使所有內容都有意義......這些都應該在數據庫中。
然後確定客戶端，中間層服務器或數據庫是否適合其他業務邏輯。
+1業務邏輯與參照完整性的好句子 – gbn 2010-08-09 17:54:55
的確，這就是我對數據庫角色的想法。我在gbn的評論中增加了更多的信息，它觸及了這件事情。感謝您的澄清，但很高興知道我正走在正確的軌道上。 – instantmusic 2010-08-09 17:56:59
多年來，我看到客戶端應用程序來來去去，但數據庫仍然存在。
因此，現在我使用大多數業務邏輯的存儲過程。三大優勢：
我同意接受一個瞬間，無需停機你建築。如果您不想管理數據庫或應用程序層的業務邏輯，那麼中間的服務層肯定是有序的。 – kbrimington 2010-08-09 17:35:39