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

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

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

附带说明。。。在某些时候，这将移交给真正的 DBA进行维护/支持，因此，我试图确保自己的生活不会更加艰难。

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

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

在该数据库中，您可能会或可能不会使用架构来组织对象。

就个人而言，我是架构的忠实拥护者，并且总是使用它们，但用于权限和逻辑分组等方面。为此，我将向您介绍以前的问题，在这些问题中您可以看到普遍支持的问题：

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

对于单独的数据库，请参见Aaron的答案，但这全都取决于“交易和参照一致”的要求。

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

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