应该避免 dbo 模式吗？

Question

当涉及到 dbo 架构时：

Answer 1

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

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

作为人力资源主管，我可以访问HR架构中的任何内容，作为IT主管，我可以查看员工的用户名和访问级别。该Engineering部门可以看到的招聘网站是活动的，等等。如果DBO是所有我有困难时分割了我的数据，并提供访问角色表设定的模式。

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

它还有助于提高可读性和可管理性。乍一看，我可以很容易地识别出哪个表保存了哪些数据以及数据是如何分离的。

我个人更喜欢将模式定义为一般实践。请记住，schema 在希腊语中是计划的意思，布局好的架构结构可以帮助您计划和识别数据。

Answer 2

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

100%支持这种方法。为了简单起见，我经常将“核心”表保留在 dbo 架构中，并在需要时开始添加。通常，我添加的第一个单独模式是“Stage”或“Staging”，以单独对我的临时表进行分组。Twitter 表示，另一个例子是添加来自外部源的数据。我将创建一个“Twitter”模式，而不是为所有表（即 TwitterAccount、TwitterStatus 等）添加前缀。 (2认同)

Answer 3

如果有的话，应该避免使用 dbo，因为它是 SQL Server 的默认值，它也根本没有描述性。像所有其他默认名称一样，因为它是预先知道的，所以它使黑客的生活变得更加轻松（尽管如果他们只是试图找出您的架构名称，您可能已经厌烦了）。

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

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

Answer 4

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

至于关于谁应该拥有它的其他问题：dbo 架构归 dbo 用户帐户所有。