Sql 如何将存储过程（即所有业务逻辑）从客户机数据库中分离出来，使其只包含客户机数据？

场景：
我们的应用程序数据库（在SQL Server 2012中）包含存储过程中的整个业务逻辑。每次我们必须将数据库发布到客户端时，都会不必要地将存储过程复制到客户端数据库

问题：
所有业务逻辑都被复制到客户端，并导致专有问题

以前尝试过的解决方案：

将

与加密一起使用

CREATE PROCEDURE Proc_Name WITH ENCRYPTION

这种方法会产生加密的、不可维护的存储过程代码。我们无法判断客户端正在运行哪个版本的代码，因此无法调试。无法应用版本控制。此外，客户端无法执行数据库复制，因为加密的存储过程不会被复制

创造同义词

CREATE SYNONYM SchemaName.Proc_Name FOR LinkedServerDB.SchemaName.Proc_Name

这允许在

Client\u DB

上创建引用（同义词），用于访问驻留在

远程链接的\u服务器\u DB

上的实际存储过程。在每个存储过程调用中，从

客户端数据库

访问整个数据，并将其传输到

远程链接服务器数据库

，在那里完成计算并将结果发送回。这会导致严重的性能问题。还需要与远程链接服务器的全天候互联网连接

要求
我们正在寻找一种解决方案，通过该解决方案，可以编译（保护）存储过程代码并将其与客户机数据库分离。此外，编译后的存储过程代码应该在客户端可用，这样客户端就不需要24x7连接到远程位置来访问存储过程。也许VisualStudio数据库项目可以用来编译存储过程代码或其他东西

[编辑]

---

我了解到SQL Server 2014允许本机编译的存储过程代码。那有帮助吗？SQL Server 2014 RTM版本是否足够稳定

与通常的看法相反，存储过程不是在SQL Server中编译的。部署时，它们以纯文本形式存储在SQL Server系统目录中，然后首先使用，查询优化器将存储过程与任何其他语句一样处理，并构造适当的执行计划，然后缓存。如果您需要保护存储过程代码的安全，那么将

与加密一起使用

是您唯一可行的选择。如果代码部署在客户端控制的服务器上，他们迟早能够访问它。为了阻止这种情况发生，你投入的精力越多，你在客户真正关心的功能上花费的资源就越少——因此你最终交付的产品就越差。你可以将存储过程逻辑转移到VB.net代码中的查询中，但你的性能会受到影响。不幸的是.Net程序集很容易被分解，因此这只增加了一层模糊，可能不值得花时间。如果您的客户可以访问数据库和.Net可执行文件，那么您就无法保护代码。为什么您不能应用版本控制？这里没有提到真正的原因。是因为它增加了内部版本管理的开销吗？据我所知，SQL Server 2014本机编译的存储过程仅适用于内存中的表。不能对数据库中的“常规”表使用本机编译的存储过程。