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