应该避免使用dbo模式吗？

关于dbo模式：

• 最佳做法是在创建数据库对象时避免使用dbo模式吗？
• 为什么应该避免dbo模式？
• 哪个数据库用户应拥有dbo模式？

这可能是一个好习惯，因为当您有其他用户使用数据库时，您希望能够限制他们对模式的访问。例如，在数据库中，您具有以下表格。

HR.Payhist
HR.Payscale
HR.Jobdesc
IT.username
IT.useraccesslevel
ENG.jobsite
ENG.trainings

作为人力资源主管，我可以访问HR架构中的任何内容，作为IT主管，我可以查看员工的用户名和访问级别。该Engineering部门可以看到哪些作业站点处于活动状态，等等。如果dbo是所有表的设置架构，那么我将很难将数据分段并提供访问角色。

我相信，SQL Server中的想法是提供一种可供不同部门访问和查询的产品。实际上，只有DBA / DBDev真正访问数据库，并且它通常仅存储应用程序数据。

它还有助于提高可读性和可管理性。乍一看，我可以轻松地确定哪个表保存哪些数据以及如何分离数据。

我个人更喜欢将模式定义为一般惯例。请记住，架构是计划的希腊文，布局好的架构结构可帮助您计划和识别数据。

我认为这确实归结于用户的偏爱，因为没有真正的技术理由要这样做。实际上，为简单起见，除非您的安全要求另有规定，否则我总是说使用dbo。当然，您也总是可以出于组织目的而这样做。

如果有的话，应该避免使用dbo，因为它是SQL Server的默认设置，它也根本不是描述性的。像所有其他默认名称一样，由于它是众所周知的，它使黑客的生活变得更加轻松（尽管如果它们只是在试图找出您的架构名称的时候，您可能已经很烦了）。

在我工作的地方，我们使用模式将数据库分为逻辑部分，并为模式分配权限。

例如，我们可能有一个带有数据库的清单系统。主表可能在inv模式中。如果我们将任何内容导入数据库，则过渡模式将用作导入过程的一部分。如果我们有任何用户不需要访问的系统存储过程，则将它们放在sp模式中。

这不是以前的最佳实践，因为在SQL 2005之前隐藏了架构，所有内容都放入了dbo架构中。SQL Server团队确实将其显示为最佳实践，并发表了一篇有关该主题的文章： SQL Server最佳实践–数据库对象架构的实现

至于其他有关谁应该拥有它的问题：dbo模式由dbo用户帐户拥有。