SQL Server 权限和视图

Question

我很好奇用户是否可以使用数据库 A 中的视图（他们有权访问数据库 A）访问数据库 B 中的表（和/或他们无权访问的其他数据库）没有用户访问数据库 B 的权限？

我的场景：

我们目前有一个数据库（数据库 A），其中存放了大部分视图。团队中的大多数用户也可以访问数据库 A。我们希望将数据库 A 中的数据表拆分到他们自己的数据库中（在同一台服务器上）。当然，当我们这样做时，视图会中断，因为它们访问的表现在将位于数据库 B 中。由于视图太多，我正在寻找一种更简单的方法。我的想法是使用数据库 A 作为视图的中心，并且在访问视图时，会为用户授予各种数据库的权限 - 而无需让他们直接访问其他数据库。

提前谢谢你。

Answer 1

我认为数据库角色作为视图访问的容器会比数据库更好。

删除对象可能比移动对象更容易。备份-恢复可以创建数据库的副本。然后删除不属于各个数据库的表和视图。

在安全性或集成方面偷工减料可能会卷土重来。如果表明显是不同系统的一部分，那么视图应该与表一起使用。通过跨数据库引用实现系统之间的安全性和集成将所有这些系统绑定到同一台服务器。 （链接服务器将是性能和 DTC 的噩梦。）我们有几个“独立”的司法应用程序（例如，DA、Public Defender、Probation 等）可以做到这一点。通过为每次使用使用数据库角色，安全性仍然得到了详细说明。集成很棒，但迁移是一场噩梦，因为它是一次性的。如果操作正确（例如，每个数据库的连接字符串），我们将能够一次移动一个数据库并一次更新和测试一个系统。就像现在一样，需要大量的项目管理和很长时间才能让每个人都做好准备。

如果表是同一个系统的一部分，那么如果数据库角色管理起来很繁琐，那么架构可能是一种分离它们的选项。将对象分离到数据库或模式中是否比管理角色更费力？

此外，如果您使用 SSDT 数据库项目，那么那些跨数据库引用（循环？）可能会很痛苦。

为了安全起见，我建议为每个需要访问的组设置一个数据库角色。没有仅用于视图的“神奇”数据库级容器。您可以做的最好的事情是 SELECT，其中包括表和视图。对于视图，创建一个脚本来授予数据库角色选择访问数据库中所有视图的权限并不难。我永远不会在表上使用授权选择然后拒绝，因为它可以阻止应该有权访问的用户访问表。如果一个或多个模式用于视图，则可以授予角色对模式的 SELECT 访问权限。这可能是最好的选择。如果视图架构和视图访问的对象具有相同的所有者，则所有权链应允许通过视图访问表。例如，如果“view”模式归“dbo”所有，那么“view”模式中的视图应该能够访问“dbo”模式中的表，而无需授予用户访问这些表的权限。 （我没试过。）

如果有第二种类型的 INSERT、UPDATE 等权限仅适用于视图，但没有，那就太好了。