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