为什么要使用数据库模式？

Question

我正在使用多个数据库模式的单个数据库,

例如
[Baz].[表3],
[Foo].[表1],
[Foo].[表2]

我想知道为什么除了组织和权限之外,这些表是以这种方式分开的.

这有多常见,还有其他好处吗？

Answer 1

在逻辑分组对象方面,您可以获得主要优势,并允许在架构级别设置权限.

它确实在编程中提供了更多的复杂性,因为您必须始终知道要从哪个模式获取内容 - 或者依赖于用户的默认模式才是正确的.同样,您可以使用它在不同的模式中允许相同的对象名称,以便代码只针对一个对象进行写入,而用户默认的模式决定哪个是.

我不会说这是常见的,有趣的是大多数人仍然放弃了dbo架构中的所有内容.

Answer 2

除了组织和权限外，我不知道其他任何可能的原因。这些不够好吗？:)

作为记录-我始终使用单个架构-但随后创建Web应用程序时，也只有一个用户。

10年后更新！

实际上，还有另一个原因。您可以出于不同目的而拥有架构的“副本”。例如，假设您正在创建一个博客平台。人们可以注册并创建自己的博客。每个博客都需要一个用于发布帖子，标签，图像，设置等的表格。一种方法是blog_id在每个表格中添加一列 ，并使用该列来区分博客。或者...您可以为每个博客创建一个新架构，为每个博客创建新表。这有几个好处：

• 编程更容易。您只需在开始时选择适当的架构，然后编写所有查询，而不必担心会忘记添加where blog_id=@currentBlog到某个地方。
• 您可以避免一类潜在的错误，即一个博客中的外键指向另一个博客中的对象（意外数据泄露！）。
• 如果要擦除博客，只需删除架构及其中的所有表。比从数十个不同的表中查找和删除记录要快得多（以正确的顺序，不过！）。
• 每个博客的性能仅取决于（无论如何，几乎总是如此）该博客中有多少数据。
• 导出数据更容易-只需转储架构中的所有对象。

当然也有缺点。

• 当您更新平台并需要执行架构更改时，您需要分别更新每个博客。
• 如果由于某种原因发生这种情况，修复损坏的数据也是如此。
• 所有平台的统计数据一起更难计算

总而言之，这是一个相当不错的小众用例，但它很方便！

Answer 3

对我来说,他们可能会导致更多问题,因为他们打破了所有权链.

例:

存储过程很容易tom.uspFoo使用表格,tom.bar但需要额外的权限 dick.AnotherTable.这意味着我必须向... dick.AnotherTable的调用者授予选择权限,tom.uspFoo从而暴露直接表访问.

除非我完全错过了什么......

编辑,2012年2月

我问过一个问题:SQL Server:权限模式如何？

关键是"同一所有者":因此如果dbo拥有两者dick和tom架构,则所有权链接都适用.我之前的回答是错的.