一千萬個為什麽

搜索

“永遠不要在代碼中做什麽,你可以讓SQL服務器為你做好” - 這是一個糟糕設計的秘訣嗎?

這是我在少數幾個地方聽過的一個想法。有些人或多或少地承認,一旦嘗試純粹在SQL中解決問題超過了一定程度的復雜性,你應該在代碼中處理它。

這個想法背後的邏輯是,對於絕大多數情況,數據庫引擎在找到完成任務的最有效方法方面比在代碼中做得更好。特別是當涉及到使結果以對數據執行的操作為條件的事情時。可以說現代引擎有效地JIT'ing +緩存查詢的編譯版本,它在表面上是有意義的。

問題是,以這種方式利用您的數據庫引擎本質上是不好的設計實踐(以及為什麽)。當數據庫中存在所有邏輯並且您只是通過ORM命中它時,線條會進一步模糊。

最佳答案

用外行的話來說:

這些是 SQL要做的事情,不管你信不信,我已經在代碼中看到過:

  • joins - codewise it'd require complex array manipulation
  • filtering data (where) - codewise it'd require heavy inserting and deleting of items in lists
  • selecting columns - codewise it'd require heavy list or array manipulation
  • aggregate functions - codewise it'd require arrays to hold values and complex switch cases
  • foreign key integrity - codewise it'd require queries prior to insert and assumes nobody will use the data outside app
  • primary key integrity - codewise it'd require queries prior to insert and assumes nobody will use the data outside app

做這些事情而不是依賴於SQL或RDBMS 會導致編寫大量沒有附加值的代碼,意味著需要調試和維護更多代碼。並且危險地假定數據庫只能通過應用程序訪問。

轉載註明原文: “永遠不要在代碼中做什麽,你可以讓SQL服務器為你做好” - 這是一個糟糕設計的秘訣嗎?