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