在C＃中存儲查詢或在Postgres中使用存儲函數？

Question

我應該將原始SQL查詢存儲在我的c＃代碼中，還是應該將它們委託給Postgres後端中的存儲函數？

如果我應該將它們存儲在代碼，因爲他們可以得到相當長的，什麼是存儲它們的最佳方式（即在一個單獨的靜態類常量）？

使用存儲函數是否對應用程序的可部署性/可更新性有任何影響？

感謝

Answer 1

我很喜歡在作爲資源嵌入到組件的文本文件存儲SQL（當我絕對有有他們的顯著數;我是一個ORM的人正常）。

當然，如何格式化該文本文件取決於您。你可以有雙換行分隔：

UpdateCustomer: 
UPDATE CUSTOMER SET NAME=@Name WHERE ID=@ID 

FindCustomer: 
SELECT NAME, ADDRESS FROM CUSTOMER 
WHERE ID=@Id 

etc 

這不是很難再有它加載一個類，進入一個類型initialier一個Dictionary<string,string>，甚至Dictionary<string,SqlStatementHelper>其中，後者是一類以方便準備具有適當價值的陳述。你可以使用任何你想要的其他格式，包括XML - 儘管如果你不需要除了名稱/數據對之外的其他任何東西，那可能是矯枉過正的。

這樣做的缺點是SQL和使用它的代碼之間的脫節 - 你不能立刻告訴參數是什麼不看文本文件。另一方面（我只是想在這裏袖口），你可能可能從具有強類型參數的方法從SQL（和一些元數據）自動生成一個類。

存儲特效的喜憂參半的是，他們住在數據庫中，而不是在你的代碼。這樣做的好處是你更有可能使它們與DDL更改保持同步。缺點是它們比本地定義的查詢更努力地改變（IME，無論如何）。 （顯然有很多其他的優點和缺點，但我限制自己在這裏的便利方面。）

至於維護 - 好吧，我想這可能是你有一個「僅數據庫」更新只是表和存儲過程，沒有任何客戶必須​​知道 - 在這種情況下，存儲的特效是一個更好的舉措。根據我的經驗（當然對於只有幾個應用程序訪問數據庫的定製解決方案，因此兼容性不是，因爲是一個問題），代碼更改幾乎無處不在，但數據庫更改不那麼簡單 - 此時存儲查詢使用應用程序意味着您更新時不太可能需要更改數據庫。這有什麼意義嗎？我還沒有喝過咖啡......

Answer 2

無論哪種方式！但通過殼體的情況下，

SQL在代碼級爲恆定，

• 值在編譯時被評估，這優化了性能。
• 它是安全的，代碼編譯或部署後無法修改。
• 通過將所有SQL文本通過線路發送到sql服務器，可能會影響性能。
• 如果SQL是動態創建的，安全性的一些缺陷。

SQL在SQL函數級別

• 安全，因爲參數 類型。
• 更容易維護數據庫模式。例如如果一個函數引用它，表格不能被刪除。
• 只需將 通過函數名稱和參數 發送到SQL服務器即可獲得更好的性能。
• 由於未編譯，所以更容易在功能級應用修補程序。 人們可以看到&修改您的代碼，因爲它以純文本形式公開。
• 維護應用程序和sql函數之間版本的一些缺點。

Answer 3

從正常的可部署性/可更新的考慮，存儲代碼的SQL查詢會限制你的選擇，因爲源代碼是不太可能部署時要重新編譯，在比較與通常的修改/ SQL存儲過程的修補程序。

當然，這也取決於你的「更新」會有多大。如果業務邏輯發生重大變化或需要數據庫切換，這一點將是情緒。

Answer 4

通常，我們通過存儲過程而不是直接SQL語句來執行所有數據庫交互;這爲調整模式更改和性能問題提供了很大的靈活性，而無需重新構建或重新部署二進制映像或配置文件到所有目標。

Answer 5

我認爲使用存儲過程更好，因爲它使用了性能。如果可能的話。

我的意思是 - 查詢和源代碼，局部變量等足夠'獨立' - 它不需要太多'準備'，你可以發送一些變量作爲參數存儲過程。