何时使用非 dbo 模式与新数据库的决策标准

Question

我主要是一名应用程序开发人员，但发现自己必须为我当前的项目（顺便说一句......它的 MS SQL Server 2008）做所有的前期数据库工作。作为第一个决定，我试图弄清楚是使用单独的数据库还是在同一数据库中使用单独的架构来划分我的状态。我对 SQL Server Schema 进行了一些阅读，这似乎是一种分离对象域（我喜欢）的自然方法，但我不确定这种模式是否存在隐藏成本。

在这两种方法之间进行选择时，我应该考虑哪些更实际的事情？如果我避免dbo.mytable赞成，myschema.mytable我是否会为我的架构带来其他挑战（或问题）？

作为旁注......在某些时候，这将被移交给真正的DBA 来维护/支持，所以我试图确保我不会让他们的生活变得更艰难。

Answer 1

我首先要说的是，不要将模式视为面向对象意义上的命名空间或对象域。模式本质上是具有一些附加值的权限容器（见下文）

此外，“单独的模式”或“单独的数据库”是两个不同的概念。需要在事务上和引用上保持一致的数据需要在同一个数据库中。看到一个数据库还是十个？博客文章了解更多。

在该数据库中，您可能会也可能不会使用模式来组织您的对象。

就个人而言，我是模式的粉丝，并且总是使用它们，但用于权限和逻辑分组之类的事情。为此，我将向您介绍以前的问题，您可以在其中看到普遍的意见是支持它们的：

• 架构设计 - 最佳实践？
• 命名表和视图时应该遵循什么标准？
• 过度使用/正确使用模式？

对于单独数据库的情况，请参阅Aaron 的回答，但这一切都取决于“事务和引用一致”的要求。

Answer 2

同意@gbn。我已经设计了使用模式进行分离和数据库进行分离的解决方案，我发现使用数据库更实用。几个原因：

1. 让您的应用程序连接到特定于上下文的数据库，然后运行相同的查询比让您的查询<schema>在所有对象引用之前注入要容易得多。这适用于许多动态 SQL，许多具有默认模式的不同应用程序登录（意味着您的代码不会使用模式前缀，依赖于应用程序用户的默认模式 - 可能导致大量计划缓存膨胀和调试困难），或者要管理很多存储过程（图片只是一个简单的报告，如果您需要每个模式一个，然后代码更改，现在您必须多次更改相同的代码，每个模式一次）。
2. 按数据库分离使您可以灵活地将繁忙的数据库移动到更快或不同的存储/实例，而无需从一个包罗万象的大型数据库中提取对象。大多数人不会提前这么长时间考虑它，但这绝对是一个潜在的规模问题。特别是如果您最终拥有一个“接管”并需要服务器上大部分资源的模式，将它们拆分可能是一项极其繁琐的任务，即使它们已经被模式分开。
3. 单独的数据库还可以让您为每个部门制定不同的维护和备份计划。我不确定你所说的“按状态划分”是什么意思，但假设你的意思是隔离客户，你可能有不同的客户对数据丢失、索引维护等有不同的要求和不同的容忍度。
4. 根据法律或公司政策，您最终可能会遇到需要您将他们的数据与其他任何人分开的客户。这在数据库级别通常是可以接受的，但模式级别通常是不够的。您现在可能没有这些客户，但如果您这样做，以后可能会成为真正的问题。