由于安全限制，每个客户都必须将其数据存储在自己的数据库中。有时，客户需要进行定制，要求修改其区域内的特定存储过程，有时是修改量很大。这给跨所有数据库维护存储过程带来了一场噩梦。看来这一定是一个经常出现的问题。是否有任何公认的标准来处理此类情况？
我考虑过的一些方法:
包含“标准”存储过程的中央数据库。进程首先检查客户端数据库中是否存在存储过程，如果不存在，则从“标准”数据库执行。问题:我无法弄清楚如何从一个数据库执行存储过程并让它引用另一个数据库中的表而不生成动态 SQL。对我来说，这似乎是最佳解决方案，因为需要维护单个存储过程，自定义很容易显而易见。我只是不知道如何让它发挥作用，如果可以的话。它始终在包含 SP 的数据库上下文中执行。
任何自定义都必须对带有 _Custom 后缀的标准存储过程的副本进行。所有存储过程调用首先测试是否存在 _Custom SP，找到时调用自定义 SP 而不是标准 SP。自定义更加明显，但是每个 SQL 调用都必须以另一个 SQL 调用为前缀以验证 SP 名称。此外，对“标准”存储过程的任何更改仍然需要在数百个数据库之间复制。
一起删除存储过程。相反，将它们作为 T-SQL 语句存储在文件或表中的某个位置。必须创建全新的管理系统来访问、测试、更新 T-SQL 代码(目前使用 Management Studio。)
我正在寻找有关如何创建一个简单而优雅的解决方案来解决此问题的信息，或者至少改进当前的情况，即手动更新每个存储过程，同时查找冲突的自定义项。
最佳答案
有一种未记录的后门方法可以实现此目的:
- 确保过程名称以
sp_开头 - 将过程放入
master - 通过执行
sp_marksystemobject 'sp_...' 将过程标记为系统
这样，该过程就可以在每个数据库中“神奇地”可用，并且它将始终作用于本地对象。例如。如果过程发出 select ... from dbo.Foo 并在数据库 bar 上下文中调用，则效果将是从 bar.dbo 选择.Foo，即使该过程是在 master 中声明的。
当然，通过使用未记录的过程(sp_marksystemobject)，您将面临使用未记录的功能的所有问题(可能会在未来版本中甚至在 SP/CU 更新中更改而不会发出警告，产品支持可能会拒绝为您提供帮助等)。
如果我处于您的位置，我会在每个租户的数据库上部署过程。真正的问题是管理变更之一，我最喜欢的解决方案在 Version Control and your Database 中描述。 .
关于sql-server - 在不同的数据库上下文下执行存储过程？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/7668021/