在不同的数据库上下文中执行存储过程？

Question

由于安全限制,每个客户必须将其数据存储在自己的数据库中.有时,客户端需要进行自定义,这些自定义需要修改其区域内的特定存储过程,有时甚至是显着的.这为在所有数据库中维护存储过程创造了一场噩梦.看来这一定是一个经常出现的问题.是否有任何公认的标准来处理这样的情况？

我考虑过的一些方法:

中央数据库包含"标准"存储过程.进程首先检查客户端数据库中是否存在存储过程,如果不存在,则从"标准"数据库执行.问题:我无法弄清楚如何从一个数据库执行存储过程,并让它在另一个数据库中引用表而不生成动态SQL.这似乎是我的最佳解决方案,因为需要维护单个存储过程,定制很容易.我甚至无法弄清楚如何让它工作,如果有的话.它总是在包含SP的数据库的上下文中执行.

必须使用_Custom后缀对标准存储过程的副本进行任何自定义.所有存储过程调用首先测试是否存在_Custom SP,在找到时调用自定义SP而不是标准SP.自定义更加明显,但每个SQL调用都必须以另一个SQL调用为前缀来验证SP名称.此外,对"标准"存储过程的任何更改仍需要在数百个数据库中进行复制.

一起删除存储过程.将它们作为T-SQL语句存储在文件或某个表中.必须创建全新的管理系统来访问,测试,更新T-SQL代码(目前使用Management Studio).

我正在寻找关于如何为这个问题创建简单而优雅的解决方案的输入,或者至少改进当前的情况,即手动更新每个存储过程,随时查找冲突的自定义.

Answer 1

有一种无证的后门方式来实现这一目标:

• 确保程序名称以 sp_
• 将程序放入 master
• 通过执行将过程标记为系统 sp_marksystemobject 'sp_...'

这样,程序在每个数据库中都 "神奇地"可用,并且它将始终作用于本地对象.例如.如果在select ... from dbo.Foo数据库的上下文中发出并调用过程bar,则效果将是选择bar.dbo.Foo,即使该过程已在声明中master.

当然,通过使用未记录的过程(sp_marksystemobject),您可以了解使用未记录的功能的所有问题(可能在将来的版本中更改无警告,甚至在SP/CU更新时,产品支持可能拒绝帮助您等).

如果我愿意,我会在每个租户的数据库上部署程序.真正的问题是管理变更,我最喜欢的解决方案在版本控制和数据库中描述.

Answer 2

关于您的第一种方法：您可以引用运行存储过程的不同数据库中的表。您只需完全限定表名称 [databaseName].[schema].[tableName].[columnName]。不需要构建一串动态 SQL。