关于dbo架构：


创建数据库对象时最好避免使用dbo架构？
为什么应该避免dbo架构？
哪个数据库用户应拥有dbo模式？


评论

一些顾问表示，避免使用dbo模式并始终创建用户定义的模式并将objets分配给这些模式是一种很好的做法。
我也从亚历山大·库兹涅佐夫（Alexander Kuznetsov）在此博客文章的评论中发现了这一声明：
是的，现在就避免。 dba.stackexchange.com/a/4109/630和dba.stackexchange.com/q/8511/630和stackoverflow.com/q/6502222/27535 @JNK：也供您参考

#1 楼

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

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


作为HR总监，我可以访问HR模式中的任何内容，就像我所看到的IT总监一样员工的用户名和访问级别。 Engineering部门可以看到哪些作业站点处于活动状态，等等。如果dbo是所有表的设置架构，则我将很难将数据分段并提供访问角色。

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

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

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

#2 楼

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

评论

此方法落后100％。为了简化起见，我经常将“核心”表留在dbo模式中，并在需要时开始添加。通常，我添加的第一个单独的架构是“ Stage”或“ Staging”，以将我的登台表单独分组。另一个例子是从外部来源（例如Twitter）添加数据。我将创建一个“ Twitter”架构，而不是给所有表加上前缀（即TwitterAccount，TwitterStatus等）。

– Pim
18年8月2日在14:03

#3 楼

如果有的话，应该避免使用dbo，因为它是SQL Server的默认设置，它也根本不是描述性的。像所有其他默认名称一样，由于它是众所周知的，它使黑客的生活变得更加轻松（尽管如果它们只是在试图找出您的架构名称的时候，您可能已经很烦了）。 >
我在这里工作，我们使用模式将数据库分为逻辑部分，并为模式分配权限。

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

评论

+1表示“避免使用它，因为它是默认设置”。强迫用户在创建对象时至少考虑一下。

– BradC
2011-12-7 21:49

#4 楼

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

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