我们有两种产品可以在客户现场实施，其中一种需要另一种存在。我在同一个数据库中实现了一个单独的模式，作为附加组件所需的数据库对象的主要产品。因为该插件理论上也可以成为未来产品的插件（尽管目前没有计划），我正在重新考虑这个决定。我们目前使用 2005，但计划在一年左右迁移到 2008 R2 或 Denali。
一个因素是在单独的 VS 2010 数据库项目中维护单独的模式很困难，因为在将项目模式与包含另一个模式的数据库进行比较时，无法将 VS 项目的视图限制为一个模式。
假设它们总是在同一个 SQL Server 实例中，是否有任何理由避免将两个模式拆分为单独的数据库？
备份由在实例中的所有数据库上运行的脚本处理，所以这不是问题。我们希望将来在托管 (SaaS) 的基础上提供产品，因此对多租户的影响是一个因素。我们可能会在一个实例中托管多个客户。
如果它们位于两个单独的数据库中，则不会获得事务一致性。根据您的 HA/DR 机制，数据库可能会不同步。例如，使用数据库镜像，一个数据库在应用事务日志方面可能远远领先于另一个数据库。镜像上的一个数据库可能在上午 10 点之前处于最新状态，但另一个数据库可能在上午 9 点 55 分之前才处于最新状态。如果发生故障转移，繁荣，您的两个数据库不同步。
请记住，在同一个数据库中，您可以强制执行外键约束，而在不编写触发器的情况下，您不能在单独的数据库中。
我认为将数据拆分到数据库而不是方案中的决定高度依赖于这些产品是否将始终一起使用而不是其他方式，我的意思是，将这些产品视为一个产品是否有意义，或者它们是否'是两种完全不同的产品一起使用。
既然您说将来您计划将附加组件也用于其他产品，我认为最好的解决方案是将数据拆分到不同的数据库中，因为稍后您将至少面临以下一种情况：
这些中的每一个都很难维护......所以我建议为你提到的场景分离数据库。
您应该（严重！）针对两种模型（单独的模式和单独的数据库）测试您的应用程序的应用程序性能。如果一个被证明是不可接受的，那就去另一个。显而易见，使用一种形式而不是其他形式的唯一真正令人信服的理由与您描述的“附加”功能有关。如果这可以是多个不同系统的“附加组件”，如果您希望所有已安装和支持的“基本”应用程序都使用单个附加组件实例，那么您非常希望将该功能封装在其中它自己的数据库实例，以便任何/所有此类实例都可以共享/访问它。
就像一个思考练习一样，如果您希望（或必须）将附加功能仅存储在“第一个”应用程序实例中，并且所有后续安装的实例都引用该代码，那么支持它的解决方案可以基于同义词（在 SQL 2005 中引入）。在安装“基础”应用程序后，必须进行检查以确定是否以及在何处找到“附加”代码，如果找到，则将参考其托管数据库构建必要的同义词。安装插件时需要类似的安装例程，以识别和更新所有支持的数据库。（这是一个有趣的想法，但就长期维护和管理而言，单独的数据库将是更好的解决方案。）