SQL Server 存储过程与外部 dll答案

【问题标题】：SQL Server stored procedure vs an external dllSQL Server 存储过程与外部 dll
【发布时间】：2011-04-02 22:15:15
【问题描述】：

我试图说服某人使用外部 DLL 来管理 sql 数据比使用存储过程更好。目前与我一起工作的人正在使用 vba 并调用 sql 存储过程来从许多不同的来源获取他们需要的复杂数据。据我了解，进行此类操作的最佳方法是使用 dll / 一些中间层来获取数据并能够根据需要对其进行格式化。

注意事项：

那么谁能告诉我使用外部 dll 然后使用 sql 存储过程的一些好处？

【问题讨论】：

不得不说我倾向于同意你同事的观点。如果您确信使用外部 dll 比使用存储过程更可取，那么您的这种信念是基于什么？到目前为止，您已经给出了一些备受争议的断言，并且似乎正在四处寻找更多“证据”来支持您的观点。
你的“理解”从何而来？是否真的需要关心缩放？您是否有实际的机会更换数据库？你的 cmets 有过早优化或太空探索的味道。

【解决方案1】：

使用存储过程，并编写您的数据访问层，该层通过单独的 dll 中的参数化命令调用它们。存储过程是一种标准，可以为您带来很多好处，参数化命令可以为您提供自动字符串安全性。

这种类型的设计基本上非常标准化，并且多年来一直如此，以至于微软已经包含了一个框架，可以在 .NET 4 中为您构建它。

或多或少，你和这个其他人都是对的，使用存储过程是为了安全，为了安全和可重用性以及很多原因分离你的 DAL

【讨论】：

【解决方案2】：

ORM/DLL 方法

专业版：

缺点：

您可以将 SQL（包括存储过程）保存在平面文件中。文件扩展名可以是 txt，但大多数使用 sql - 使得将 SQL 源存储在 CVS/etc 中与 .NET 或 Java 源代码相比没有实际意义。

【讨论】：

【解决方案3】：

同意关于控制代码的观点，在 DLL 中更容易。与源代码控制相同。但是，从纯粹的性能角度来看，存储过程将获胜，因为它们是编译的，而不仅仅是缓存。我不知道它是否会产生足够的影响，但我想我会把它扔进去。

使用存储过程也可以更加安全，因为您可以锁定对存储过程的访问，并且您不必（必须）将您的表数据暴露给任何有连接的人。

我想我并没有真正回答你的问题，而是指出你的论点中的漏洞。对此很抱歉，但我是从他们的角度来看的。

【讨论】：

【解决方案4】：

我真的认为这归结为偏好问题。就我个人而言，我喜欢 ORM 并在 DLL 中保存查询而不是存储过程，我发现它们比将 S.Procs 部署到数据库更容易维护和分发。不过，S.Proc 相对于原始查询有一些特定的优势。一些优化和一些服务器端逻辑可以提高某些领域的性能。

总而言之，我个人更喜欢在代码中工作而不是在 DB mumbo-jumbo 中工作，所以这就是我选择 DLL 方法的真正原因。

此外，您还可以将源代码保存在源代码控制中，使用存储过程要困难得多。

只是我的 2c。

【讨论】：

SQL Server Management Studio，至少是较新的版本，将连接到源代码控制系统，因此控制 SP 源代码并不难。我们用设置和权限语句包装我们的直接 sp 源，并将其置于源代码控制之下。这真的很简单。