SQL Server：分离模式还是分离数据库？

Question

我们有两个产品在客户现场实施，其中一个需要另一个产品的存在。我在同一数据库中为附加组件所需的数据库对象实现了单独的模式。由于附加组件理论上也可能成为未来产品的附加组件（尽管目前没有计划），因此我正在重新考虑这个决定。我们目前使用2005，但计划在一年左右迁移到2008 R2或Denali。

一个因素是，在不允许将VS项目的视图限制为与包含另一个模式的数据库进行比较时，维护单独的模式在单独的VS 2010数据库项目中很困难。

如果假设这两个模式始终在同一个SQL Server实例中，有什么理由避免将它们拆分为单独的数据库吗？

备份由操作所有实例中的所有数据库的脚本处理，因此这不是一个问题。我们希望将产品将来提供为托管（SaaS）基础上，因此对多租户的影响是一个因素。我们可能会在一个实例中托管多个客户。

- Mark Freeman

Answer 1

如果它们在两个不同的数据库中，您将无法获得事务一致性。根据您的HA / DR机制，数据库可能会失去同步。例如，使用数据库镜像，一个数据库可以比另一个数据库在应用事务日志方面领先很多。镜像上的一个数据库可能最新到10AM，而另一个数据库只有到9:55AM。在故障转移的情况下，您的两个数据库将不再同步。

- Brent Ozar

---

如果数据库（文件，例如数据和事务日志）托管在SQL Server的不同实例上，则非常正确...但我认为他是在谈论所有数据库都由单个实例托管。 - Philip Kelley

是的，这是一个重要的区别。SQL Server是否在实例内跨数据库保持事务一致性？在我们的情况下，一个模式中的触发器包含对另一个模式执行的DML操作。如果我在该句子中将“模式”更改为“数据库”（同样假设在同一实例内），那么DML中的故障会导致触发器触发的事务回滚吗？ - Mark Freeman

Answer 2

请记住，您可以在同一数据库中强制执行外键约束，而在不编写触发器的情况下，无法在单独的数据库中执行该操作。

- HLGEM

Answer 3

我认为将数据拆分到数据库而不是方案中的决定高度取决于这些产品是否总是一起使用，没有其他方式，我的意思是，如果考虑将这些产品视为一个整体是否有意义，或者它们是两个完全不同的产品一起使用。

由于您说未来计划将附加组件用于其他产品，因此我认为最好的解决方案是在不同的数据库中拆分数据，因为以后您将面临以下至少一种情况：

• 您为另一个产品安装了附加组件，并且其中包含当前产品的信息（至少是数据库架构）。
• 您将不得不每次与其他产品一起安装单独的附加组件数据库。

每个都很难维护...因此，我建议针对您提到的场景拆分数据库。

- PedroC88

Answer 4

你应该（严格！）测试应用程序性能，针对两种模型（独立架构和独立数据库）。如果其中一种被证明不可接受，则选择另一种。显而易见的是，使用一种形式而不是另一种形式的唯一真正引人注目的原因与您描述的“附加”功能有关。如果这可以成为多个不同系统的“附加组件”，如果您希望单个“附加组件”实例被所有已安装和支持的“基本”应用程序使用，则几乎肯定需要将该功能封装在其自己的数据库实例中，以便它可以被任何/所有这样的实例共享/访问。

仅作为思考练习，如果您想要（或必须）仅将附加功能存储在“第一个”应用程序实例中，并使所有随后安装的实例引用该代码，则支持它的解决方案可以基于同义词（在SQL 2005中引入）。在安装“基本”应用程序时，必须进行检查，确定是否找到了“附加”代码以及其所在位置，如果找到，则需要构建必要的同义词引用其托管数据库。当安装附加组件时，也需要类似的安装程序，以识别和更新所有支持的数据库。（这是一个有趣的想法，但独立数据库将是长期维护和管理的更好解决方案。）

- Philip Kelley