【发布时间】：2011-01-13 19:10:32
【问题描述】：
受到我见过的各种架构相关问题的启发......
Ownership chaining 允许我在没有明确权限的情况下对存储过程执行 GRANT EXECUTE 对我使用的表，如果存储过程和表都在同一个架构中。
如果我们使用单独的模式，那么我必须在不同模式表上显式地 GRANT XXX。所有权链接示例证明了这一点。这意味着执行存储过程的用户可以直接读/写您的表。
这就像直接访问类中的实例变量，绕过 getter/setter，破坏封装。
我们还使用行级安全性来限制某人看到的内容，并将其应用到存储过程中。
那么，我们如何保持模式分离并防止直接表访问？
当然，如果您使用 ORM 或不使用存储过程，该问题将不适用。但我不问我是否应该使用 ORM 或存储过程，以防有人觉得需要启发我......
编辑，示例
CREATE USER OwnsMultiSchema WITHOUT LOGIN
GO
CREATE SCHEMA MultiSchema1 AUTHORIZATION OwnsMultiSchema
GO
CREATE SCHEMA MultiSchema2 AUTHORIZATION OwnsMultiSchema
GO
CREATE USER OwnsOtherSchema WITHOUT LOGIN
GO
CREATE SCHEMA OtherSchema AUTHORIZATION OwnsOtherSchema
GO
CREATE TABLE MultiSchema1.T1 (foo int)
GO
CREATE TABLE MultiSchema2.T2 (foo int)
GO
CREATE TABLE OtherSchema.TA (foo int)
GO
CREATE PROC MultiSchema1.P1
AS
SELECT * FROM MultiSchema1.T1
SELECT * FROM MultiSchema2.T2
SELECT * FROM OtherSchema.TA
Go
EXEC AS USER = 'OwnsMultiSchema'
GO
--gives error on OtherSchema
EXEC MultiSchema1.P1
GO
REVERT
GO
CREATE PROC OtherSchema.PA
AS
SELECT * FROM MultiSchema1.T1
SELECT * FROM MultiSchema2.T2
SELECT * FROM OtherSchema.TA
Go
GRANT EXEC ON OtherSchema.PA TO OwnsMultiSchema
GO
EXEC AS USER = 'OwnsMultiSchema'
GO
--works
EXEC OtherSchema.PA
GO
REVERT
GO
编辑 2：
- 我们不使用“跨数据库所有权链接”
- 行级安全性是一条红鲱鱼，无关紧要：我们不会在任何地方都使用它
【问题讨论】：
-
为了清楚起见，是否可以提供您正在描述的单独架构场景的编码示例？在您的场景中，这两个独立的架构是否具有相同的所有者？
-
为什么要为 serverfault 投票关闭？它适用于代码猴子，而不是系统管理员......
标签： sql-server-2005 sql-server-2008 permissions schema encapsulation