我不是初学者使用SQL数据库，特别是SQL Server . 但是，我主要是一个SQL 2000的人，我在2005年总是对模式感到困惑 . 是的，我知道模式的基本定义，但它们在典型的SQL Server部署中真正使用了什么？
我一直只使用默认架构 . 为什么我要创建专门的模式？为什么要分配任何内置模式？
编辑：澄清一下，我想我正在寻找架构的好处 . 如果您只是将它用作安全方案，那么数据库角色似乎已经填满了......呃..嗯..角色 . 使用它作为命名空间说明符似乎是你可以用所有权完成的事情（dbo与用户等等） .
我想我得到的是，Schemas做了什么，你不能做所有者和角色？他们的特殊利益是什么？
11 回答
模式逻辑上将表，过程，视图组合在一起 .
employee架构中的所有与员工相关的对象等 .您还可以只为一个模式授予权限，以便用户只能看到他们有权访问的模式，而不能看到任何其他模式 .
就像C＃代码的命名空间一样 .
它们还可以为插件数据提供一种命名冲突保护 . 例如，SQL Server 2008中新的更改数据捕获功能将其使用的表放在单独的cdc架构中 . 这样，他们就不必担心CDC表和数据库中使用的真实表之间的命名冲突，并且就此而言可以故意遮蔽真实表的名称 .
我知道这是一个旧线程，但我只是自己查看模式并认为以下可能是架构使用的另一个好方法：
在Datawarehouse中，来自不同来源的数据，您可以为每个来源使用不同的模式，然后例如控制基于模式的访问 . 还避免了各种来源之间可能的命名冲突，正如上面回复的另一张海报 .
如果保持模式不连续，则可以通过将给定模式部署到新数据库服务器来扩展应用程序 . （这假设您有一个足够大的应用程序或系统具有不同的功能） .
例如，考虑执行日志记录的系统 . 所有日志记录表和SP都在[logging]架构中 . 记录是一个很好的例子，因为很少（如果有的话）系统中的其他功能将与日志模式中的对象重叠（即连接） .
使用此技术的提示 - 为应用程序/系统中的每个模式使用不同的连接字符串 . 然后，将架构元素部署到新服务器，并在需要扩展时更改连接字符串 .
我倾向于同意布伦特的观点...在这里看到这个讨论 . http://www.brentozar.com/archive/2010/05/why-use-schemas/
简而言之......除了非常具体的用例外，模式并不是非常有用 . 使事情变得混乱 . 如果你能提供帮助，请不要使用它们 . 并尝试遵守K（eep）I（t）S（实施）S（tupid）规则 .
在我工作多年的ORACLE商店中，模式用于封装适用于不同前端应用程序的程序（和包） . 每个应用程序的不同“API”架构通常都是有意义的，因为用例，用户和系统要求完全不同 . 例如，一个'API'模式仅供开发人员使用的开发/配置应用程序 . 另一个“API”架构用于通过视图和过程（搜索）访问客户端数据 . 另一个“API”模式封装了用于将开发/配置和客户端数据与具有自己的数据库的应用程序同步的代码 . 这些'API'模式中的一些，在有意义的情况下仍然可以与彼此（通过其他'COMMON'模式）共享通用过程和函数 .
我会说没有架构可能不是世界末日，尽管它可能非常有用 . 实际上，SQL Server中缺少的包确实在我脑海中产生了问题......但这是一个不同的主题 .
我没有看到对与Schemas绑定的用户进行别名的好处 . 这就是为什么....
大多数人最初通过角色将他们的用户帐户连接到数据库，只要您以任何形式将用户分配给sysadmin或数据库角色db_owner，该帐户就会被别名为“dbo”用户帐户，或者已满数据库的权限 . 一旦发生这种情况，无论您如何将自己分配给超出默认架构（与您的用户帐户具有相同名称）的方案，这些dbo权限都将分配给您在用户和架构下创建的对象 . 它有点无意义.....只是一个命名空间，并混淆了这些对象的真正所有权 . 如果你问我那么糟糕的设计....谁设计它 .
他们应该做的是创建“组”，抛出模式和角色，只允许你以你喜欢的任何组合对组进行分层，然后在每个层告诉系统是否使用自定义权限继承，拒绝或覆盖权限 . 这将更加直观，并允许DBA更好地控制真正的所有者对这些对象的看法 . 现在它隐含在大多数情况下dbo默认的SQL Server用户拥有这些权利....而不是用户 .
我认为模式就像许多新功能（无论是SQL Server还是其他任何软件工具） . 您需要仔细评估将其添加到开发工具包中的好处是否抵消了设计和实现中简单性的损失 .
在我看来，模式大致相当于可选的名称空间 . 如果您处于对象名称冲突并且权限的粒度不够精确的情况，那么这是一个工具 . （我倾向于说可能存在设计问题，首先应该在更基础的层面上处理 . ）
问题可能是，如果它存在，一些开发人员将开始随意使用它以获得短期利益;一旦它在那里它可以成为葛 .
在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，也不会影响架构 .
开发 - 我们的每个开发人员都将自己的架构作为沙盒来玩 .