database - 業務邏輯:數據庫或應用層




oracle business-logic (16)

只要你保持一致 ,這完全取決於你。

將它放在數據庫層中的一個很好的理由:如果您非常確定您的客戶端永遠不會更改其數據庫後端。

將其放在應用程序層中的一個很好的理由:如果您要為應用程序定位多個持久性技術。

您還應該考慮核心競爭力。 您的開發人員主要是應用程序層開發人員,還是主要是DBA類型?

https://code.i-harness.com

古老的問題。 您應該將業務邏輯放在數據庫中作為存儲過程(或包),還是應用程序/中間層? 更重要的是,為什麼?

假設數據庫獨立性不是目標。


任何影響數據完整性的事情都必須放在數據庫級別。 除了用戶界面之外的其他事情通常是將數據放入,更新或刪除數據庫中的數據,包括導入,批量更新以更改定價方案,熱修復等。如果您需要確保始終遵循規則,請將邏輯置於默認值和触發器。

這並不是說在用戶界面中也沒有它是一個好主意(為什麼要發送數據庫不會接受的信息),但忽略數據庫中的這些東西是為了惹惱。


商務應用程序'層'是:

1.用戶界面

這實現了業務用戶對h(is / er)作業的看法。 它使用用戶熟悉的術語。

2.處理

這是計算和數據操作發生的地方。 涉及更改數據的任何業務邏輯都在此處實現。

3.數據庫

這可能是:規範化的順序數據庫(標準的基於SQL的DBMS); 一個OO數據庫,存儲包裝業務數據的對象; 等等

什麼去哪裡

在進入上述層時,您需要進行必要的分析和設計。 這將指示最佳實現業務邏輯的位置:數據完整性規則和有關數據更新的並發/實時問題通常會盡可能接近數據實現,與計算字段相同,這是一個很好的指針存儲過程/觸發器,絕對需要數據完整性和事務控制。

涉及數據含義和使用的業務規則大部分將在處理層中實現,但也將作為用戶的工作流出現在用戶界面中 - 以反映出的一些順序鏈接各種流程用戶的工作。


在數據庫中放入足夠的業務邏輯,以確保數據的一致性和正確性。

但是不要害怕必須在另一個級別複製一些邏輯以增強用戶體驗。


在這種情況下,提問者排除作為考慮因素的數據庫獨立性是將邏輯排除在數據庫之外的最強有力的論據。 數據庫獨立性的最有力論據是能夠將軟件銷售給具有自己的數據庫後端優先權的公司。

因此,我認為將存儲過程從數據庫中取出的主要論點僅僅是商業過程,而不是技術過程。 可能存在技術原因,但也存在將其保留在其中的技術原因 - 性能,完整性以及允許多個應用程序使用相同API的能力。

是否使用SP也會受到您要使用的數據庫的強烈影響。 如果不考慮數據庫獨立性,那麼使用T-SQL或使用PL / SQL將會有非常不同的體驗。

如果您使用Oracle開發應用程序,那麼PL / SQL作為一種語言顯然是一種選擇。 它與數據緊密耦合,在每個關係中不斷改進,任何體面的開發工具都會將PL / SQL開發與CVS或Subversion或其他類似的整合。

Oracle的基於Web的Application Express開發環境甚至可以使用PL / SQL 100%構建。


將代碼放在應用程序層中將導致數據庫獨立的應用程序。

出於性能原因,有時最好使用存儲過程。

它(像往常一樣)取決於應用要求。


恕我直言。 在決定關係數據庫驅動的應用程序中業務邏輯的位置時,存在兩個相互矛盾的問題:

  • 可維護性
  • 可靠性

回覆。 可維護性:為了實現有效的未來開發,業務邏輯屬於應用程序中最容易調試和版本控制的部分。

回覆。 可靠性:當存在重大不一致風險時,業務邏輯屬於數據庫層。 可以設計關係數據庫來檢查數據的約束,例如,不允許特定列中的NULL值等。當您的應用程序設計中出現某些數據需要處於特定狀態的情況時,這些狀態太複雜而無法用這些簡單表達約束,在數據庫層中使用觸發器或類似的東西是有意義的。

觸發器是一個很難掌握的最新動態,特別是當您的應用程序應該在您甚至無法訪問的客戶端系統上運行時。 但這並不意味著無法跟踪它們或更新它們。 S.Lott在他的回答中斷言,這是一個痛苦和麻煩是完全有效的,我會把它排在第二位並且也在那裡。 但是,如果您在第一次設計數據層時考慮到這些限制,並且除了絕對必需品之外不要使用觸發器和函數,那麼它是可管理的。

在我們的應用程序中,大多數業務邏輯包含在應用程序的模型層中,例如發票知道如何從給定的銷售訂單初始化自己。 當為這樣一組複雜的變化順序修改一堆不同的東西時,我們在事務中將它們匯總以保持一致性,而不是選擇存儲過程。 總計等的計算都是使用模型層中的方法完成的。 但是當我們需要對某些內容進行非規範化處理或將數據插入到所有客戶端使用的“更改”表中以確定它們需要在會話緩存中過期的對象時,我們使用數據庫層中的觸發器/函數來插入新行並從此觸發器發出通知(Postgres listen / notify stuff)。

在我們的應用程序在現場使用了大約一年,每天都有數百名客戶使用,如果我們從頭開始,我唯一要改變的就是設計我們的系統來創建數據庫功能(或存儲過程,但是你想要打電話給他們)從一開始就考慮到版本控制和更新。

值得慶幸的是,我們確實有一些系統來跟踪模式版本,因此我們在此基礎上構建了一些內容來處理替換數據庫函數。 如果我們考慮到從一開始就需要更換它們,它現在可以節省我們一些時間。

當然,當你走出RDBMS領域之外的一切都會變成像Amazon SimpleDB和Google的BigTable這樣的元組存儲系統。 但那是一個不同的故事:)


我們在存儲過程中加入了許多業務邏輯 - 它並不理想,但通常它在性能和可靠性之間取得了很好的平衡。

我們知道它的位置,而無需搜索大量的解決方案和代碼庫!


數據庫中唯一的東西就是數據。

存儲過程是維護的噩夢。 它們不是數據,不屬於數據庫。 開發人員和DBA之間的無休止協調只不過是組織摩擦。

很難對存儲過程保持良好的版本控制。 數據庫外部的代碼非常容易安裝 - 當您認為版本錯誤時,您只需執行SVN UP(可能是安裝)並將應用程序恢復到已知狀態。 您有應用程序的環境變量,目錄鏈接和許多環境控制。

通過簡單的PATH操作,您可以使用適用於不同情況的變體軟件(培訓,測試,QA,生產,客戶特定的增強等等)。

但是,數據庫中的代碼更難管理。 沒有合適的環境 - 沒有“PATH”,目錄鏈接或其他環境變量 - 提供對正在使用的軟件的任何可用控制; 你有一套永久的,全球範圍內的應用軟件,這些應用軟件停留在數據庫中,與數據結合在一起。

觸發器更糟糕。 它們既是維護又是調試的噩夢。 我不明白他們解決了什麼問題; 它們似乎是一種解決設計糟糕的應用程序的方法,在這種應用程序中,有些人無法正確使用可用的類(或函數庫)。

雖然有些人發現性能參數引人注目,但我仍然沒有看到足夠的基準數據來說服我存儲過程都那麼快。 每個人都有一個軼事,但沒有人有並排的代碼,其中算法或多或少相同。

[在我看過的例子中,舊的應用程序是一個設計糟糕的混亂; 在編寫存儲過程時,應用程序被重新構建。 我認為設計變更比平台變化更具影響力。


根據我的經驗,答案取決於一系列價值觀,這些價值觀通常取決於貴組織的技能所在。

DBMS是一種非常強大的野獸,這意味著適當或不恰當的治療會帶來巨大的好處或巨大的危險。 可悲的是,在太多的組織中,主要關注編程人員; dbms技能,尤其是查詢開發技能(與管理相對)被忽略了。 由於評估dbms技能的能力也可能缺失,這一點更加嚴重。

並且很少有程序員能夠充分理解他們對數據庫的不了解。

因此,次優概念的普及,如Active Records和LINQ(引入一些明顯的偏見)。 但它們可能是這些組織的最佳答案。

但是,請注意,高度規模的組織傾向於更加關注數據存儲的有效使用。


業務邏輯應作為第一選擇放在應用程序/中間層中。 這樣,它可以以域模型的形式表示,放在源代碼控制中,拆分或與相關代碼(重構)等組合。它還為您提供了一些數據庫供應商獨立性。

面向對象的語言也比存儲過程更具表現力,使您能夠更好,更容易地在代碼中描述應該發生的事情。

在存儲過程中放置代碼的唯一好理由是:如果這樣做會產生重要且必要的性能優勢,或者如果相同的業務代碼需要由多個平台(Java,C#,PHP)執行。 即使在使用多個平台時,也存在可能更適合共享功能的Web服務等替代方案。


業務邏輯通常由對像以及封裝,繼承和多態的各種語言構造體現。 例如,如果銀行應用程序正在轉移資金,則可能存在Money類型,其定義了“資金”的業務元素。 這與使用原始小數來表示金錢相反。 出於這個原因,精心設計的OOP是“業務邏輯”所在的地方 - 嚴格來說不是任何層。


這個問題沒有獨立的正確答案。 這取決於您的應用程序的要求,開發人員的偏好和技能,以及月亮的階段。


這是一個很好的問題! 在我問過一個類似question後我發現了這個question ,但這更具體。 它是由於我沒有參與製作的設計變更決定而產生的。

基本上,我被告知的是,如果數據庫表中有數百萬行數據,那麼請考慮將業務邏輯放入存儲過程和触發器中。 這就是我們現在正在做的事情,將Java應用程序轉換為存儲過程以實現可維護性,因為java代碼已經變得複雜。

我發現這篇文章: 業務邏輯大戰作者還在一個表格參數中創建了百萬行,我覺得這很有趣。 他還在javascript中添加了業務邏輯,javascript是客戶端和業務邏輯層之外的。 我之前沒有想過這個,即使我多年來一直使用javascript進行驗證,還有服務器端驗證。

我的觀點是,您希望應用程序/中間層中的業務邏輯作為經驗法則,但不要打算將其放入數據庫的情況。

最後一點,還有另一個我正在工作的小組正在為研究做大量的數據庫工作,他們正在處理的數據量是巨大的。 儘管如此,對於他們來說,他們在數據庫本身並沒有任何業務邏輯,而是將其保留在應用程序/中間層。 對於他們的設計,應用程序/中間層是它的正確位置,因此我不會將表的大小用作唯一的設計考慮因素。


雖然在應用程序層上擁有業務邏輯肯定有好處,但我想指出語言/框架似乎比數據庫更頻繁地更改。

我支持的一些系統在過去的10到15年中經歷了以下UI:Oracle Forms / Visual Basic / Perl CGI / ASP / Java Servlet。 沒有改變的一件事 - 關係數據庫和存儲過程。


雖然沒有一個正確的答案 - 這取決於有問題的項目,我會推薦Eric Evans在“ Domain Driven Desig n”中提倡的方法。 在這種方法中,業務邏輯在其自己的層中被隔離 - 域層 - 位於基礎架構層之上 - 可能包括您的數據庫代碼,並位於應用層之下,後者將請求發送到域層履行並聽取確認完成,有效推動申請。

通過這種方式,業務邏輯被捕獲在一個模型中,可以與那些除了技術問題之外了解業務的人討論,並且應該更容易隔離業務規則本身的變化,技術實現問題和流程。與業務(域)模型交互的應用程序。

如果你有機會,我建議閱讀上面的書,因為它非常擅長解釋這個純粹的理想如何在真實的代碼和項目的現實世界中實際近似。





business-logic