Sql server 多应用实例数据库设计理论

我正在从事一个SaaS项目，每个客户都有一个应用程序实例（customer1.application.com、customer2.application.com等），理想情况下，每个客户在数据库中都有自己的“空间”。当前的计划是为每个客户创建一个DB，并将应用程序的一个实例部署到web场中。我们的想法是，每个客户都可以选择不升级以维持现状（这是我们的一位投资者真正想要的，部分原因是他讨厌Facebook不断改变它的工作方式。）

昨天晚上，我试图对我的两个测试帐户进行一次更改数据库的更新。虽然随后导致的错误是我的错（忘记了DDL中一个很小但显然非常重要的更改），但我开始担心我的整体操作理论，因为缺少一个ALTER COLUMN语句和整个升级周期可能会被吹到地狱。经过长时间的积累，我的问题是：

1） 是否有一种方法可以在两个数据库（“测试”生产数据库和实际生产数据库）之间进行区分，从而准确记录所做的每个更改

2） 我是否应该考虑其他数据库（和/或应用程序）设计模型？我知道，若我去掉了对应用程序多个版本的支持，实际上我就消除了很多长期支持方面的难题

您不应该手动更改DBs。通过执行所有DDL更改的脚本来完成此操作，等等

理想情况下，应该有一个使用DDL版本作为配置/输入的通用DB发布脚本

（和DDL更改应在版本控制系统中使用特定标记进行标记）

您可以选择Microsoft route re：支持多个版本是一件令人头痛的事情-只需将X之前的所有版本（比如说2个版本）指定为不受支持。这样，您就可以支持最新的2-3版本，但不会在其他方面浪费资源，同时在很大程度上允许每个客户端的灵活性

您应该仔细权衡使用您建议的版本化app/DB系统的利弊

列出优点（例如安抚投资者，在您提到的版本意外更改时为客户提供积极体验-转化为保留/添加需要此类功能的新客户的边际概率，，再加上一种简单的BETA/UAT测试，再加上一种失败的方式来回滚出错的模式更改通过将客户机的数据从以前的版本加载到DB模式中）

列出缺点（数据库空间成本、实施时间成本、支持成本）

比较两者并决定哪一个对您的业务更有利。

Redgate's在比较和区分两个SQL Server数据库（警告：商业第三方产品）方面做得很好。此外，我认为还有一些免费的东西可以做同样的事情

---

如果您希望能够让一些客户留在您产品的旧版本上，那么维护每个客户一个数据库模型可能更有意义，其中包含用于在源代码控制下构建每个版本数据库的脚本。这样可以使您的客户彼此隔离，甚至允许您切换数据库供应商（例如从SQL Server到Oracle）或版本（例如从SQL Server 2000到SQL Server 2005）在某些客户上，而让其他客户使用旧版本。

手动运行脚本将不起作用。实际上，diff工具也不起作用。diff适用于2,4或10个数据库。但不可扩展，因为您需要的是出现故障时的可靠性（脱机数据库、服务器重新启动等等）

您可以通过安排升级脚本进行部署。例如，请参阅MySpace如何为1000多个数据库执行此操作：。关键在于它们使用有保证、可靠的交付机制（SSB）部署架构维护脚本。您需要一个异步、可靠的机制来运行脚本，因为目标数据库可能处于脱机状态，正在运行计划维护、非CAHBE等，而像Service Broker这样的可靠传递机制可以处理所有重试和相关问题（处理重复项、确认等）。您还可以查看如何通过SSB处理脚本执行的示例

至于脚本本身，我建议您开始将数据库架构和配置数据视为版本化资源

更新

我想我有一些解释为什么我会选择一种错误的方法。为了弄清楚，我说的是几百个服务器和数千个数据库的部署。原来的帖子与脸谱网相比，我希望他们能成功地达到这个规模，但是问题也问到设计原则，所以我说。关于云层尺度的讨论是恰当的

我发现diff工具存在两个问题：

• 可用性。所有差异工具都通过连接到“主”和“副本”来工作，因此它们只能在两者都在线的情况下才能完成工作。这会创建一个热点，一个单点故障，“主”副本，其可用性对于部署升级至关重要。高可用性总是要付出代价的。它还留下了“c”的问题opy的可用性作为次要的实施细节，升级方案必须自行处理重试、超时和与客户端的断开连接（无论如何都不是一个小问题）

• 原子性。diff工具期望“master”有一个稳定的模式。这实际上会在升级过程中冻结“master”。虽然这可以在小范围内控制，但在大范围内，它会成为一个问题，因为将master本身升级到v.N+1会与所有数千个数据库竞争，而其中一些数据库可能是我将从v.N-1升级

基于脚本的解决方案