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