面向多应用实例的数据库设计理论

Question

我正在开发一个SaaS项目，让每个客户都有一个应用程序实例(customer1.application.com、customer2.application.com等)。理想情况下，每个客户都应该在数据库中拥有自己的“空间”。当前的计划是为每个客户创建一个数据库，并将应用程序的一个实例部署到web场中。我们的想法是，每个客户都可以选择退出升级，以维持现状(这是我们的一位投资者真正想要的，很大程度上是因为他讨厌Facebook不断改变其运作方式)。

昨天晚上，我试图向我的两个测试账户推出一个改变了数据库的更新。虽然随后导致的错误是我的错(忘记了DDL中一个很小但显然非常重要的更改)，但我开始担心我的整个操作理论，因为缺少一条ALTER COLUMN语句和整个升级周期可能会导致地狱。因此，在长时间的积累之后，我的问题是：

1)有没有一种方法可以在两个数据库(“测试”生产数据库和实际生产数据库)之间进行比较，从而准确地记录所做的每个更改？

2)我是否应该考虑其他数据库(和/或应用程序)设计模型？我知道，如果我取消了对应用程序的多个版本的支持，那么实际上我就消除了很多长期的支持难题。

Answer 1

思想食粮：

代码升级比DB Schema升级更频繁。确保您有一个非常好的 SCM来处理代码升级。我们使用git取得了巨大的成功。

代码很容易管理，数据库则不容易(相比之下)。原因是它们是可变的，并且每时每刻都在变化。此外，它们真的很难回滚(有可能，但很耗时，因为停机)。因此，我们必须找到一种简单的方法来跟踪模式更新(以及相关的数据更改)，并能够在将来将其应用于其他类似的数据库。

应该为每个数据库架构版本提供一个唯一的、连续的整数版本号。从每次说100个开始。

每次您必须升级它时，编写一个sql脚本，比如

• 100-101.sql
• 101-102.sql
• 102-103.sql

执行该特定版本的升级是每个脚本的工作。它可以像添加一个表一样简单，也可以像重新排列外键一样复杂。但在任何情况下，它们都将是可靠的，因为它们的设计目标是什么。

您可以在测试期间多次应用任何给定的脚本(在新数据上)，以确保它将按预期工作。

因此，当您发现自己需要将客户端从130版升级到180版时，您可以安全地应用sql脚本(按顺序)，并且您将到达正确的目的地。

Answer 2

1. 您永远不应该手动更改数据库。通过执行所有DDL更改的脚本执行此操作，等等。

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

(并且DDL更改应该在版本控制系统中使用特定的标签进行标记)

• 您可以转到微软路由re:支持令人头疼的多个版本-只需将X之前的所有版本(例如2个版本)指定为不受支持。这样，你可以支持最新的2-3个版本，但不会在更多的东西上浪费资源，同时在很大程度上允许每个客户端的灵活性。

• 你应该仔细权衡你提议的版本应用/数据库系统的利弊。

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

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

将两者进行比较，决定哪个更适合您的业务。

Answer 3

Redgate的SQL Compare在比较和区分两个SQL Server数据库方面做得很好(警告:商业第三方产品)。另外，我认为市面上有很多免费的东西可以做同样的事情。

如果您希望能够让一些客户使用旧版本的产品，那么维护一个每个客户一个数据库的模型可能更有意义，该模型包含用于在源代码管理下构建每个版本的数据库的脚本。这使您的客户彼此隔离，甚至允许您切换某些客户的数据库供应商(例如，从SQL Server切换到Oracle)或版本(例如，从SQL Server 2000切换到Sql Server 2005)，同时让其他客户继续使用旧版本。