如何设计SaaS数据库

大约10年前,面对类似的情况,我们选择了每个客户机一个数据库。我们有成百上千的客户。回顾过去,这是我们做出的最好的决定之一。备份很容易。将单个客户端复制到我们的办公室进行分析很容易(只需进行最后一次备份)。扩展很容易(将单个大客户机移动到不同的服务器可以释放sql server上的资源)。乔尔;杰夫在一次会议上讨论了这个问题 stack overflow podcast (不是最近的)joel做了和我一样的事。。。每个客户机都有自己的数据库。数据库纯粹主义者通常会主张将所有人都集中到一个数据库中,但我绝不会这样做。

-堂

我应该为每个公司创建一个新的数据库吗?

是的,唐·迪金森很有钱。但是,请参见下面的改进。

公司名称?

上帝啊,不!为不同的客户端更改数据库查询将使您发疯!此外,您几乎肯定会运行动态SQL(在运行查询之前,表名在代码中更改),这会损害性能,因为大多数服务器都喜欢缓存查询计划和临时结果——如果表名不断更改,这将不起作用。

只需添加一个公司

因此,您可能会说,“免费试用”和“青铜”客户都集中在一个数据库中,使用公司id将它们分开silver“用户拥有自己的数据库(但您仍然在模式中保留customer_id字段,因此不必在两个级别的customer之间更改查询),“gold”客户拥有自己的数据库服务器。

几年前,我在一家SaaS公司做了类似的事情——客户通常很乐意在基础设施(读作:性能和弹性)以及功能方面有一个升级路径。

将每个服务器或服务器实例保留在其自己的服务器或服务器实例上,使我们能够使用相同的名称保持数据库结构不变,并且更容易将更改传播到所有服务器,因为我们不必更改数据库名称。

如果确实为每个客户端使用单独的实例,请确保设计并实现了一个良好的系统,用于将所有更改传播到所有客户端。如果这些数据库不同步,它们可能会变得难以维护。你会发现,如果你让它们失去同步,每个客户端都会要求更改,你将有27种方法来做同样的事情。当它们在同一个数据库上时,您必须进行概括,当它们分开时,您必须使用自律来确保每个客户机的新功能是相同的。

这要视情况而定,在这里,我在一家与其他公司一样拥有许多“内部业务部门”的公司工作。 因此,一些报告必须包括所有公司,客户账户也必须在公司之间共享。在这里,表中有一个CompanyId字段需要它。 前缀解决方案肯定是一个需要避免的方案。