架构,MS SQL中对象的所有者

默认情况下,使用dbo所有者/模式设置对象(表,存储过程等)(我认为ms sql 2000将其称为所有者,而ms sql 2005将其称为模式)

所有者/架构实际上是数据库中的角色或用户.我总是保留默认的dbo,但我最近在微软培训书中看到了一些例子,其中一些表和存储过程有不同的所有者/模式.这样做有什么好处？为什么？

当您遇到安全问题时,使用模式会非常有用.

如果您有多个访问数据库的应用程序,您可能不希望后勤部门访问人力资源记录.因此,您将所有人力资源表放入hr模式,并且只允许hr角色中的用户访问它.

未来六个月,物流现在需要知道内部费用帐户,这样他们就可以将所有这些蓝色笔的调色板发送到正确的位置.然后,您可以创建一个存储过程,该存储过程以具有查看hr模式和物流模式权限的用户身份执行.物流用户永远不需要知道HR中发生了什么,但他们仍然可以获得他们的数据.

您也可以像cfeduke建议的那样使用模式,并使用它们在对象浏览器中对事物进行分组.如果你这样做,请小心,因为当你真的只需要一个dbo.Address时,你最终可能会创建Person.Address和Company.Address(我不是在敲你的例子,cfeduke,只是用它来说明两者地址表可能相同,也可能不同,YMMV).

在SQL 2000中,Schema与数据库用户等效,在SQL 2005中,每个模式都是一个独立的命名空间,独立于创建它的数据库用户.

当我需要创建稍后可能在其他项目中使用的功能或模块时,我使用模式,因此我将能够隔离模块使用的数据库对象.

我在过去的类似命名空间中使用了模式,因此您可以拥有多个名为Address([Person].[Address],[Company].[Address])的实体.这样做的好处是SQL Management Studio中的可视化组织,您可以通过将所有内容放在一个模式下并使用单个标识符(即[dbo].[PersonAddress])命名表来获得相同的功能.

在我们所有开发机器上运行SQL Server Developer Edition之前,我还将它们用于开发人员与开发人员开发(当我在职业生涯早期使用集中式开发数据库时).