SQL Server存儲過程與外部dll

Question

我試圖說服某人，使用外部DLL管理sql數據比使用存儲過程更好。 目前，我正在與之打交道的人正在使用vba，並調用sql存儲過程以從許多不同的來源獲取所需的復雜數據。 據我了解，執行此類操作的最佳方法是使用dll /中間層來獲取數據並能夠將其格式化為需要的格式。

注意事項：

• 我正在與之共事的人並不關心能夠擴展到更大范圍，而現在我們
• 他們不在乎能夠切換到不同的平台
• 他們認為目前的設置沒有太大的性能問題
• 使用dll需要做更多不同方向的工作
• 如果當前的操作方式沒有當前問題，他們不想切換（所以只是因為它的正確方式行不通...我嘗試過）

那么誰能告訴我使用外部dll然后使用sql存儲過程的一些好處？

Answer 1

使用存儲過程，並編寫數據訪問層，該數據訪問層通過參數化的命令在單獨的dll中調用它們。 存儲過程是標准操作，可為您帶來很多好處，參數化命令可為您提供自動的字符串安全性。

這種類型的設計基本上已經標准化，並且已經使用了多年，以至於Microsoft在.NET 4中包含了一個為您構造它的框架。

或多或少，您和另一個伙伴都是正確的，使用sprocs來確保安全，並出於安全性和可重用性而將您的DAL分開，原因很多

Answer 2

ORM / DLL方法

優點：

• 您不必學習SQL或存儲過程語法

缺點：

• 在單個事務中使多個操作復雜化
• 冒着增加應用程序與數據庫之間旅行的風險，這意味着數據同步/並發問題
• 在復雜的查詢中完全失敗； 因此，大多數通過ORM支持存儲過程

您可以將SQL（包括存儲過程）保存在平面文件中。 文件擴展名可以是txt，但是大多數使用sql-可以將SQL源代碼存儲在CVS / etc中，而不是.NET或Java源代碼。

Answer 3

同意有關控制代碼的要點，在DLL中要容易得多。 與源代碼管理相同。 但是，從純粹的性能角度來看，存儲過程將勝出，因為它們是經過編譯的，而不僅僅是緩存的。 我不知道這是否會帶來足夠的改變，但我想我會考慮一下。

使用存儲過程也可以更加安全，因為您可以僅鎖定對存儲過程的訪問，而不必（不必）向有連接的任何人公開表數據。

我想我沒有真正回答您的問題，還沒有指出您的論點中的漏洞。 抱歉，但是我從他們的角度來看。

Answer 4

我真的認為這歸結為偏好問題 。 我個人比較喜歡ORM和將查詢保存在DLL與存儲的Procs中，與將S.Procs部署到數據庫相比，我發現它們更易於維護和分發。 與原始查詢相比，S.Proc具有某些優勢。 一些優化和一些服務器端邏輯可以提高某些方面的性能。

總而言之，我個人更喜歡在代碼中工作，而不是在DB Mumbo-jumbo中工作，因此，這就是為什么我選擇DLL方法的原因。

另外，您也可以將源代碼也保留在源代碼控制中，而使用存儲過程則要困難得多。

只是我的2c。