SQL Server架构有什么好处？

我不是使用SQL数据库（尤其是SQL Server）的初学者。但是，我主要是从事SQL 2000的工作，在2005年以来，我一直对架构感到困惑。是的，我知道架构的基本定义，但是它们在典型的SQL Server部署中真正用于什么？

我一直只使用默认架构。我为什么要创建专门的架构？为什么要分配任何内置模式？

编辑：为澄清起见，我想我正在寻找模式的好处。如果您仅打算将其用作安全方案，则似乎数据库角色已经填补了这个角色。使用它作为名称空间说明符似乎已经可以通过所有权（dbo与用户等）来完成。

我想我要问的是，您无法使用所有者和角色执行的模式是什么？他们有什么特别的好处？

模式在逻辑上将表，过程，视图组合在一起。employee架构中所有与员工相关的对象，等等。

您还可以仅授予一个模式权限，以便用户只能看到他们有权访问的模式，而没有其他权限。

就像C＃代码的命名空间一样。

它们还可以为插件数据提供一种命名冲突保护。例如，SQL Server 2008中新的“更改数据捕获”功能将其使用的表放在单独的cdc架构中。这样，他们不必担心CDC表和数据库中使用的真实表之间的命名冲突，因此可以故意隐藏真实表的名称。

我知道这是一个旧线程，但是我只是亲自研究了架构，并认为以下内容可能是架构使用的另一个不错的选择：

在数据仓库中，数据来自不同的源，您可以为每个源使用不同的架构，然后例如基于该架构控制访问。还避免了各种来源之间可能的命名冲突，如上面另一个回答。

如果您保留架构的离散性，则可以通过将给定的架构部署到新的数据库服务器来扩展应用程序。（这假定您的应用程序或系统足够大以具有独特的功能）。

例如，考虑执行日志记录的系统。所有日志记录表和SP都在[logging]模式中。日志记录是一个很好的例子，因为很少（如果有的话）系统中的其他功能会重叠（即加入）日志记录模式中的对象。

使用此技术的提示-为您的应用程序/系统中的每个模式使用不同的连接字符串。然后，将架构元素部署到新服务器，并在需要扩展时更改连接字符串。

我倾向于在这个问题上同意布伦特...在这里看到这个讨论。http://www.brentozar.com/archive/2010/05/why-use-schemas/

简而言之，除了非常特定的用例之外，模式并不是非常有用。使事情变得混乱。如果可以帮助，请不要使用它们。并尝试遵守K（eep）I（t）S（imple）S（tupid）规则。

我看不出将与模式相关联的用户别名掉的好处。这就是为什么。

大多数人最初都是通过角色将其用户帐户连接到数据库。将用户分配给sysadmin或数据库角色db_owner（以任何形式）后，该帐户要么被别名为“ dbo”用户帐户，要么已经具有完整权限。数据库权限。一旦发生这种情况，无论您如何将自己分配给默认架构（与用户帐户名称相同）之外的方案，这些dbo权限都将分配给您在用户和架构下创建的对象。它有点没有意义.....只是一个名称空间，混淆了那些对象的真实所有权。如果您问我，它的设计很差。

他们应该做的是创建“组”，并丢弃模式和角色，只允许您按自己喜欢的任意组合对组进行分层，然后在每一层告诉系统权限是否被继承，拒绝或被自定义覆盖那些。这本来会更加直观，并且可以让DBA更好地控制真正的所有者在那些对象上。现在，在大多数情况下，它隐含着dbo默认SQL Server用户具有这些权限。

在我工作多年的ORACLE商店中，模式用于封装适用于不同前端应用程序的过程（和程序包）。由于用例，用户和系统要求完全不同，因此每个应用程序通常使用不同的“ API”架构。例如，一个“ API”模式仅用于开发/配置应用程序，仅供开发人员使用。另一个“ API”模式用于通过视图和过程（搜索）访问客户端数据。另一个“ API”模式封装的代码用于将开发/配置和客户端数据与拥有自己数据库的应用程序进行同步。这些“ API”模式中的某些模式，在幕后，仍将彼此共享共同的过程和功能（通过其他“ COMMON”

我会说，没有模式可能不是世界末日，尽管这可能会很有帮助。确实，SQL Server中缺少软件包的确在我脑海中引发了问题……但这是一个不同的话题。

我认为架构就像许多新功能一样（无论是SQL Server还是任何其他软件工具）。您需要仔细评估将其添加到开发套件中的好处是否可以抵消设计和实施中的简单性损失。

在我看来，模式大致相当于可选的名称空间。如果您遇到对象名称冲突且权限粒度不够精细的情况，请使用以下工具。（我倾向于说可能首先要在更基本的层次上处理设计问题。）

问题可能是，如果有的话，一些开发人员将开始随便使用它以获取短期利益。一旦进入，它就会变成葛根。

在SQL Server 2000中，创建的对象链接到该特定用户，例如，假设某个用户（例如Sam）创建了一个对象（例如，Employees），则该表将显示为：Sam.Employees。如果Sam离开公司或搬到其他业务领域怎么办？一旦删除用户Sam，Sam.Employees表将如何处理？可能需要先将所有权从Sam.Employees更改为dbo.Employess。模式提供了解决此问题的解决方案。Sam可以在诸如Emp_Schema之类的模式中创建他的所有对象。现在，如果他在Emp_Schema中创建对象Employees，则该对象将被称为Emp_Schema.Employees。即使需要删除用户帐户Sam，该架构也不会受到影响。

开发-我们的每个开发人员都可以将自己的模式作为沙箱使用。

这是在SQL Server中使用架构的一个很好的实现示例。我们有几个ms-access应用程序。我们希望将它们转换为ASP.NET App门户。每个ms-access应用程序都被编写为该门户的应用程序。每个ms-access应用程序都有其自己的数据库表。其中一些是相关的，我们将它们放在SQL Server的通用dbo模式中。其余的都有自己的模式。这样，如果我们想知道哪些表属于ASP.NET应用程序门户上的某个应用程序，可以轻松地对其进行导航，可视化和维护。