SQL Server 架构有什么好处？
我不是使用 SQL 数据库的初学者，尤其是 SQL Server。但是，我主要是使用 SQL 2000 的人，并且一直对 2005 年及以后的模式感到困惑。是的，我知道架构的基本定义，但它们在典型的 SQL Server 部署中真正用于什么？
我一直只使用默认模式。为什么我要创建专门的模式？为什么我要分配任何内置模式？
编辑：澄清一下，我想我正在寻找模式的好处。如果您只打算将其用作安全方案，那么似乎数据库角色已经填补了那个.. er.. um.. 角色。并且使用它作为命名空间说明符似乎是您可以通过所有权完成的事情（dbo 与用户等）。
我想我的意思是，Schemas 做了哪些所有者和角色不能做的事情？它们的具体好处是什么？
模式在逻辑上将表、过程、视图组合在一起。 employee 架构中所有与员工相关的对象等。
您还可以仅授予一个模式的权限，以便用户只能看到他们有权访问的模式，而不能看到其他任何内容。
就像 C# 代码的命名空间一样。
MyDatabase.MySchema 架构中的表不会神奇地映射到 MyProject.MyDatabase.MySchema 命名空间中的实体类。还值得注意的是，表名中的任何点表示法 (.) hack 最终都会在类名中作为下划线 (_)。只是不幸的想法的食物。
它们还可以为插件数据提供一种命名冲突保护。例如，SQL Server 2008 中新的变更数据捕获功能将它使用的表放在单独的 cdc 架构中。这样，他们就不必担心 CDC 表和数据库中使用的真实表之间的命名冲突，并且可以故意隐藏真实表的名称。
我知道这是一个旧线程，但我自己只是研究了模式，并认为以下可能是模式使用的另一个很好的候选者：
在数据仓库中，由于数据来自不同的来源，您可以为每个来源使用不同的模式，然后例如基于模式控制访问。还避免了各种来源之间可能的命名冲突，正如上面另一位发帖人所回答的那样。
如果您保持架构离散，则可以通过将给定架构部署到新数据库服务器来扩展应用程序。 （这假设您有一个足够大以具有不同功能的应用程序或系统）。
例如，考虑一个执行日志记录的系统。所有日志记录表和 SP 都在 [logging] 模式中。日志是一个很好的例子，因为系统中的其他功能很少（如果有的话）会与日志模式中的对象重叠（即加入）。
使用此技术的提示——在您的应用程序/系统中为每个模式使用不同的连接字符串。然后将架构元素部署到新服务器并在需要扩展时更改连接字符串。
在我工作多年的 ORACLE 商店，模式用于封装适用于不同前端应用程序的过程（和包）。每个应用程序使用不同的“API”模式通常是有意义的，因为用例、用户和系统要求完全不同。例如，一个“API”模式用于开发/配置应用程序，仅供开发人员使用。另一个“API”模式用于通过视图和过程（搜索）访问客户端数据。另一个“API”模式封装的代码用于将开发/配置和客户端数据与拥有自己数据库的应用程序同步。这些“API”模式中的一些，在其合理的情况下，仍然会彼此共享通用过程和功能（通过其他“通用”模式）。
我会说没有模式可能不是世界末日，尽管它可能非常有用。确实，SQL Server 中缺少包确实在我的脑海中产生了问题……但这是一个不同的话题。
我倾向于同意布伦特的观点……请参阅此处的讨论。 http://www.brentozar.com/archive/2010/05/why-use-schemas/
简而言之......除了非常特定的用例之外，模式并不是非常有用。让事情变得一团糟。如果您能提供帮助，请不要使用它们。并尝试遵守 K(eep) I(t) S(imple) S(tupid) 规则。
我没有看到将与模式绑定的用户混叠的好处。这就是为什么....
大多数人最初通过角色将他们的用户帐户连接到数据库，一旦您以任何形式将用户分配给系统管理员或数据库角色 db_owner，该帐户要么别名为“dbo”用户帐户，要么具有完整的数据库的权限。一旦发生这种情况，无论您如何将自己分配给默认架构（与您的用户帐户同名）之外的方案，这些 dbo 权限都会分配给您在用户和架构下创建的那些对象。它有点毫无意义……只是一个命名空间，混淆了这些对象的真正所有权。如果你问我，它的设计很糟糕......无论是谁设计的。
他们应该做的是创建“组”，并丢弃模式和角色，只允许您以您喜欢的任何组合对组组进行分层，然后在每一层告诉系统权限是否被继承、拒绝或被自定义覆盖那些。这将更加直观，并允许 DBA 更好地控制这些对象的真正所有者。现在它在大多数情况下暗示 dbo 默认 SQL Server 用户拥有这些权限....而不是用户。
我认为模式就像很多新功能（无论是 SQL Server 还是任何其他软件工具）。您需要仔细评估将其添加到您的开发套件的好处是否可以抵消设计和实现中的简单性损失。
在我看来，模式大致相当于可选的命名空间。如果您处于对象名称冲突且权限粒度不够精细的情况，这里有一个工具。 （我倾向于说可能存在应该首先在更基本的层面处理的设计问题。）
问题可能是，如果它存在，一些开发人员会开始随便使用它来获取短期利益；一旦它在那里，它就可以变成葛根。
在 SQL Server 2000 中，创建的对象链接到该特定用户，例如，如果用户说 Sam 创建了一个对象，比如员工，则该表将显示为：Sam.Employees。如果 Sam 离开公司或搬到其他业务领域怎么办？删除用户 Sam 后，Sam.Employees 表会发生什么情况？可能，您必须首先将所有权从 Sam.Employees 更改为 dbo.Employess。 Schema 提供了解决此问题的解决方案。 Sam 可以在诸如 Emp_Schema 之类的模式中创建他的所有对象。现在，如果他在 Emp_Schema 中创建一个对象 Employees，那么该对象将被称为 Emp_Schema.Employees。即使需要删除用户帐户 Sam，架构也不会受到影响。
开发 - 我们的每个开发人员都有自己的模式作为沙盒来玩。
这是使用 SQL Server 架构的一个很好的实现示例。我们有几个 ms-access 应用程序。我们希望将它们转换为 ASP.NET 应用程序门户。每个 ms-access 应用程序都被编写为该门户的应用程序。每个 ms-access 应用程序都有自己的数据库表。其中一些是相关的，我们将它们放在 SQL Server 的公共 dbo 模式中。其余的都有自己的模式。这样，如果我们想知道哪些表属于 ASP.NET 应用程序门户上的某个应用程序，可以轻松导航、可视化和维护。
