我应该使用多个数据库吗？

Question

我有一种情况，我需要为一些面包店设计一个数据库。我需要为很多面包店设计同样的东西。例如，对于每一家面包店，我将拥有一个雇员表和一个产品表(实际上，这将更加复杂)。雇员和产品之间确实有关系，但一个面包店的实体从来没有与另一个面包店的实体有任何关系。我在想，与其建立一个有面包店实体的数据库，不如建立几个只有员工和产品的数据库，然后从我需要的数据库中提取数据，而面包店正是根据这个数据库提出要求的。因为每个面包店都会有完全相同的桌子，同样的属性，面包店永远不会相互影响，我想这可能是个好主意。

这显然是一个测试示例，我正在为一个web应用程序类项目工作，所以我对此非常陌生，我不确定是否存在这样的东西。

• 人们会这样做(在这样的情况下，将数据分散在多个数据库中)吗？
• 是不是太慢了？
• 仅仅是制作一个烘焙实体，然后索引它会更好吗，即使我的数据库图会变得更加复杂吗？

Answer 1

在现实世界中，很大程度上取决于你有多少客户，这些客户有多偏执/数据有多有价值，以及你的客户有多偏斜(例如，妈妈和爸爸每天有10件商品，每天100次销售，而Hostess Inc公司每天销售数百万次)。

单独的数据库会产生各种管理问题。例如，每次您想要进行升级时，都必须确保在每个数据库中运行相同的脚本。如果你支持1万家面包店，那是很有挑战性的。特别是当脚本完美地工作在其中的9900个并且在100个数据库中生成稍微不同的错误时，因为它们碰巧有一个您没有预料到的数据条件，或者因为当时不同的后台作业正在运行，现在您必须手动查看100个错误日志来查看如何修复每个数据库(同时，您的中间层代码被成功地推入并假定新的对象存在，这对100个客户是不正确的)。当然，您可以通过完全自动部署和充分测试回滚脚本，并回滚9900个数据库，因为100个数据库失败而成功升级，从而缓解这些问题。但是，这需要一个相当复杂的部署管道，例如，在较低的环境中可以使用所有10000个数据库来测试部署脚本，并且每个人都严格地验证它们的回滚脚本(这是非常罕见的)。

如果使用您的服务来处理他们非常敏感的信息的客户数量相对较少，那么这样做是完全合理的。如果您有100个数据库，因为您有100个医院链作为客户将病人信息放在您的系统中，那么这种水平的努力可能是非常合理的。如果你想为很多小面包店提供一种低成本的方式来管理相对较少的员工和产品，这可能是不合理的。

如果您有一个非常大的和非常小的客户组合，不同的客户可能希望相同的查询使用不同的计划，或者某些大客户希望能够划分他们的工作负载(例如，Hostess想知道只有4个应用服务器和一个数据库服务器，并且当您向数据库服务器添加4个核心时，他们将得到所有这些，并且您希望向Hostess收取应用程序企业版的费用，以授予他们使用专用硬件的特权)，将一小撮大客户放在自己的数据库中，并将所有的小鱼苗组合到他们自己的共享数据库中，这可能是有意义的。

实际上，这意味着您可能会使用一个bakery实体来设计它，因为您知道将来有一天您可能实际上选择将其中一些数据库部署到表中的一行。也许最初您将所有东西都放在一个数据库中，然后移动到两个地理位置不同的数据库中(即，所有澳大利亚客户都进入您从澳大利亚数据中心运行出来的数据库中)，然后将真正的大客户移到他们自己的数据库中，其中bakery实体只有一行。然后，当Hostess几年后来找你，想把Hostess欧洲和Hostess美国分开，用不同的员工和产品，你可以在同一个数据库中把它们设置成单独的面包店。