SQL Server模式有什么好处?

我不是使用SQL数据库的初学者，尤其是SQL Server。然而，我主要是一个SQL 2000的人，我总是对2005+的模式感到困惑。是的，我知道模式的基本定义，但是在典型的SQL Server部署中，它们真正用于什么呢?

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

编辑:为了澄清，我想我是在寻找模式的好处。如果您只打算将其用作安全方案，那么似乎数据库角色已经填补了这一空白。呃. .嗯. .的角色。使用它作为名称空间说明符似乎是可以用所有权(dbo vs . user，等等)来完成的事情。

我想我想说的是，模式能做哪些所有者和角色不能做的事情?它们的具体好处是什么?

126353 次浏览
小开
最佳答案

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

您还可以只给一个模式赋予权限，这样用户就只能看到他们有权访问的模式，而不能看到其他模式。

小开

开发-我们的每个开发人员都有自己的模式作为沙盒来玩。

小开

它们还可以为插件数据提供一种命名冲突保护。例如，SQL Server 2008中的新更改数据捕获特性将它使用的表放在一个单独的cdc模式中。这样，他们就不必担心CDC表和数据库中使用的真实表之间的命名冲突，并且可以故意掩盖真实表的名称。

小开

我认为模式就像很多新特性(无论是SQL Server还是其他软件工具)。您需要仔细评估将其添加到开发工具包的好处是否可以抵消设计和实现中简单性的损失。

在我看来，模式大致相当于可选名称空间。如果您处于对象名称发生冲突且权限粒度不够细的情况下，这里有一个工具。(我倾向于说，可能有一些设计问题应该首先在更基本的层面上解决。)

问题在于，如果它存在，一些开发者会为了短期利益而随意使用它;一旦放进去，就会变成葛藤。

小开

就像c#代码的Namespace一样。

小开

我知道这是一个旧的线程，但我自己刚刚研究了模式，并认为下面可能是模式使用的另一个很好的候选:

在数据仓库中，对于来自不同来源的数据，您可以为每个来源使用不同的模式，然后根据模式控制访问。也避免了不同来源之间可能的命名冲突，就像上面另一个帖子回复的那样。

小开
在SQL Server 2000中，创建的对象链接到特定的用户，比如用户 Sam创建了一个对象，比如Employees，这个表将显示为:Sam.Employees。什么 关于山姆是否要离开公司或去其他业务领域。一旦你删除 用户山姆，会发生什么。员工表?也许，你必须改变 所有权首先来自山姆。Employees to dbo.Employess。模式提供解决方案 克服这个问题。Sam可以在一个模式(例如Emp_Schema)中创建他的所有对象。 现在，如果他在Emp_Schema中创建了一个对象Employees，那么该对象将是 被称为Emp_Schema.Employees。即使需要删除用户帐户Sam，也可以删除

. Schema不会受到影响
小开

如果保持模式离散，则可以通过将给定模式部署到新的DB服务器来扩展应用程序。(这假设您有一个足够大的应用程序或系统，具有不同的功能)。

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

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

小开

我看不出将绑定到schema的用户别名化有什么好处。原因如下....

大多数人最初通过角色将用户帐户连接到数据库。一旦以任何形式将用户分配给sysadmin或数据库角色db_owner，该帐户要么别名为“dbo”用户帐户，要么具有对数据库的完全权限。一旦发生这种情况，无论您如何将自己分配到缺省模式(与您的用户帐户具有相同的名称)之外的方案，这些dbo权限都会分配给您在用户和模式下创建的对象。这有点毫无意义.....只是一个名称空间，混淆了这些对象的真正所有权。如果你问我，它的设计很糟糕....不管是谁设计的。

他们应该做的是创建“组”，抛出模式和角色，只允许你以任何你喜欢的组合对组进行分层，然后在每一层告诉系统权限是否被继承、拒绝或覆盖自定义权限。这将更加直观，并允许DBA更好地控制谁是这些对象的真正所有者。目前在大多数情况下dbo默认SQL Server用户拥有这些权限....而不是用户。

小开

在我工作多年的ORACLE商店，模式被用来封装应用于不同前端应用程序的过程(和包)。对于每个应用程序使用不同的“API”模式通常是有意义的，因为用例、用户和系统需求非常不同。例如，一个“API”模式是开发/配置应用程序，只供开发人员使用。另一个“API”模式用于通过视图和过程(搜索)访问客户端数据。另一种“API”模式封装了用于将开发/配置和客户端数据与拥有自己数据库的应用程序同步的代码。其中一些“API”模式，在有意义的地方，仍然会彼此共享共同的过程和函数(通过其他“common”模式)。

我想说的是，没有模式可能不是世界末日，尽管它可能非常有帮助。真的，在我看来，SQL Server中缺少包才是真正造成问题的原因。但那是另一个话题了。

小开

在这一点上，我倾向于同意布伦特的观点。请看这里的讨论。http://www.brentozar.com/archive/2010/05/why-use-schemas/

总之……除了非常特定的用例，模式并不是特别有用。把事情弄得一团糟。尽量不要使用它们。试着遵守K(eep) I(t) S(imple) S(tupid)规则。

小开

这里有一个在SQL Server中使用模式的很好的实现示例。我们有几个ms访问应用程序。我们想把它们转换成ASP。NET应用程序门户。每个ms访问应用程序都是为该门户编写的应用程序。每个ms-access应用程序都有自己的数据库表。其中一些是相关的，我们把它们放在SQL Server的通用dbo模式中。其余部分有自己的模式。这样，如果我们想知道哪些表属于ASP上的应用程序。NET应用程序门户，可以轻松导航，可视化和维护。


提交答案