题 SQL Server架构有什么用?


我不是初学者使用SQL数据库,特别是SQL Server。但是,我主要是一个SQL 2000的人,我一直对2005年以上的模式感到困惑。是的,我知道模式的基本定义,但它们在典型的SQL Server部署中真正使用了什么?

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

编辑:澄清一下,我想我正在寻找架构的好处。如果您只是将它用作安全方案,那么数据库角色似乎已经填满了......呃..嗯..角色。使用它作为命名空间说明符似乎是你可以用所有权完成的事情(dbo与用户等等)。

我想我得到的是,Schemas做了什么,你不能做所有者和角色?他们的特殊利益是什么?


159
2018-02-09 17:47


起源




答案:


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

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


136
2018-02-09 17:50



从管理角度来看,为模式分配权限的可能性使其值得。 - Hakan Winther
你不能使用单独的数据库吗? - sam yi
这种架构许可听起来不错......但很少使用得当。对我而言,这不值得麻烦。 - sam yi
但是,如果是这种情况,你不能使用命名约定实现相同的目标吗?我并不是说它没有用例;它通常是通过减法来增加的。 - sam yi
@ Ajedi32,是的...使用模式,您可以在单个事务日志中获得单个原子提交,并一次性恢复所有数据,而不是两个数据库不同步以及对抗分布式事务。 - Matthew Whited


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


30
2017-09-06 08:28



不幸 但是,从ORM的角度来看,模式和.NET命名空间并不能很好地协同工作(即实体框架)。表中的 MyDatabase.MySchema schema不会神奇地映射到实体类中 MyProject.MyDatabase.MySchema 命名空间。值得注意的是任何点符号(.)表名中的黑客最终将成为下划线(_)在班级名称中。只是不幸的想法的食物。 - Dan Lugg
当然,“C#代码的命名空间”不允许ACL。 - Hogan
教学的好比喻。我不认为它是100%字面意思......(那些警告在实践中听起来很小) - Samantha Branham
就个人而言,我希望他们 是 更像是.NET命名空间,这样可以嵌套任意数量的模式(就像命名空间一样)用于组织目的。那,我希望他们能在EF中更好地映射。 - Dan Lugg


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


27
2018-02-09 17:54





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

在Datawarehouse中,来自不同来源的数据,您可以为每个来源使用不同的模式,然后例如控制基于模式的访问。还避免了各种来源之间可能的命名冲突,正如上面回复的另一张海报。


15
2017-12-16 07:29





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

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

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


8
2017-12-27 18:33





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

简而言之......除了非常具体的用例外,模式并不是非常有用。使事情变得混乱。如果你能提供帮助,请不要使用它们。并尝试遵守K(eep)I(t)S(实施)S(tupid)规则。


7
2017-12-05 22:06



我不认为Brent认为“模式很糟糕”,只是使用非默认模式比使用默认模式要复杂得多。其余的总和是准确的。 - Joseph Daigle
“如果正确使用[模式],它们会让您按对象组隔离权限。” 〜 brentozar.com/archive/2010/05/why-use-schemas - L. L. Learner


我没有看到对与Schemas绑定的用户进行别名的好处。这就是为什么....

大多数人最初通过角色将他们的用户帐户连接到数据库,只要您以任何形式将用户分配给sysadmin或数据库角色db_owner,该帐户就会被别名为“dbo”用户帐户,或者已满数据库的权限。一旦发生这种情况,无论您如何将自己分配给超出默认架构(与您的用户帐户具有相同名称)的方案,都会将这些dbo权限分配给您在用户和架构下创建的对象。它有点无意义.....只是一个命名空间,并混淆了这些对象的真正所有权。如果你问我那么糟糕的设计....谁设计它。

他们应该做的是创建“组”,抛出模式和角色,只允许您按照自己喜欢的任何组合对组进行分层,然后在每个层告诉系统是否继承,拒绝或覆盖自定义权限那些。这将更加直观,并允许DBA更好地控制真正的所有者对这些对象的看法。现在它隐含在大多数情况下dbo默认的SQL Server用户拥有这些权利....而不是用户。


6
2017-10-22 22:01





在我工作多年的ORACLE商店中,模式用于封装适用于不同前端应用程序的程序(和包)。每个应用程序的不同“API”架构通常都是有意义的,因为用例,用户和系统要求是完全不同的。例如,一个'API'模式仅供开发人员使用的开发/配置应用程序。另一个“API”架构用于通过视图和过程(搜索)访问客户端数据。另一个“API”模式封装了用于将开发/配置和客户端数据与具有自己的数据库的应用程序同步的代码。这些'API'模式中的一些,在有意义的情况下仍然可以与彼此(通过其他'COMMON'模式)共享通用过程和函数。

我会说没有架构可能不是世界末日,尽管它可能非常有用。实际上,SQL Server中缺少的包确实在我脑海中产生了问题......但这是一个不同的主题。


6
2017-11-02 18:47



对于Oracle,由于1个实例= 1个数据库= 1个支付许可证,人们使用shemas避免创建另一个数据库并支付另一个许可证。在SQl Server中,1台服务器可以处理大量数据库。 - Patrick Honorez


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

在我看来,模式大致相当于可选的名称空间。如果您处于对象名称冲突并且权限的粒度不够精确的情况,那么这是一个工具。 (我倾向于说可能存在设计问题,首先应该在更基础的层面上处理。)

问题可能是,如果它存在,一些开发人员将开始随意使用它以获得短期利益;一旦它在那里它可以成为葛。


4
2018-02-09 18:48





在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需要删除,也是如此 架构不会受到影响。


3
2018-06-28 06:45



这已不再适用,因为自2000年以来已有两个新版本 - Hogan