单个V / s多个数据库

我已经构建了这个Web应用程序（php和mysql），该应用程序存储了各种组织的信息（当前大约有20个客户端）。

当前方案将与客户端相关的信息存储在各个数据库中，因此有20个客户端数据库和1个主数据库。

这里的主要优点之一是，由于隔离了每个客户端数据库，因此对客户端工件（报告，审计）等的编号进行了排序。给我们的客户一种安全感。

每个数据库大约有15个表，一个表中的最多行大约为2000。预计最多将增加5000条记录。

管理一个数据库级别的更改意味着要更改20个数据库，但是在极少数情况下，我需要进行这样的更改，因此我使用了在单个函数调用中执行此操作的脚本。

我们采用共享托管方式，而我们的ISP向我们提供数量有限的服务。数据库；这就是促使我思考集中数据库的原因。这样所有客户端数据都可以存储在master数据库中。

当然，出现的一些重要问题是：

一种。保持工件序列（可以通过创建其他参考密钥来解决）b。速度和性能（在这种情况下，我可以创建索引来加快速度）c。安全性：将在每个获取客户端信息的查询中进行管理。还将跟踪他们的client_id

将来，我们可能需要考虑将一个组织的数据集与另一个组织的数据集进行比较，但是我相信这也可以在集中式数据库上实现。我出于某种原因（出于性能和可维护性的考虑）倾向于使用集中式数据库。

您认为迁移到集中式数据库是否比保持现状（在单个数据库上）更有意义？

谢谢你的建议。

这两个系统都有继承风险和回报。我曾在一家金融公司工作，该公司在1个数据库上为大约40个客户（国家银行）提供支持。然后，我们购买了另一家销售类似软件的公司，并且每个客户只有一个数据库。最终，公司破产了，我们确实必须导出所有用户数据。这是我与之共事的人，我发现：

单数据库专业版：

1. 软件更新和错误修复更容易。
2. 易于管理和报告所有客户数据。
3. 更新数据变得更加容易。
4. 易于创建一个客户端想要的模块化功能，如果其他客户端关闭，则将其关闭，然后在将来他们需要时将其关闭。

单一数据库的缺点：

1. 数据完整性-我们有2或3种情况，其中1家银行的用户看到了另一家银行的数据。这是一场噩梦。特别是因为站点用户不仅是银行员工，而且是银行的实际账户持有客户！这是迄今为止1个数据库的最大问题
2. 导出客户端数据-当我们必须这样做时，通常没什么大不了的。您最终得到1个表，其中包含所有客户端，然后从该表中键入数据以获取特定于客户端的数据。

多个数据库的专业版：

1. 无需担心跨客户端数据受到污染或破坏
2. 导出客户端数据非常简单。

多个数据库的缺点：

1. 更新和错误修复-这是真正的噩梦。当您在20个不同的数据库上有20个客户端时，您会很快遇到一种情况：一个客户端想要修复错误，而另一个客户端则认为该错误是一项功能或不想冒险进行更新。此外，您将有一个实例，其中有一个客户端想要增强游戏功能，而其他客户端则不需要。发生这种情况时，数据库将开始分散。突然，您将不得不使用1个脚本16-19更新另一个客户端，并使用第三个脚本20更新客户端1-15。我们看到这成为一个问题，导致所购买公司的错误修复所花费的时间比我们购买公司的时间长15到20倍，因为他们必须为每个客户运行所有测试并处理每个客户的特殊代码。实际上，他们为每个新客户都需要一个新的支持人员，
2. 数据库管理-当您接触到大量的客户时，管理所有数据库就变得很麻烦。毫无疑问，您将需要更多的DBA时间来管理它们。

最后，我的建议是既要做到又要做到“纪律”！我认为多数据库选择会更好一些，因为它可以保护您，但您永远无法让客户做出让您仅向他们添加功能的选择，否则您将陷入失败的道路。

我要为单独的客户提供单独的数据库。客户端出于安全原因可能会要求这样做-即只有其站点可以访问其数据。这也意味着，如果客户端要移动其数据，则将更易于管理。

这也意味着，如果一个客户端的数据库出现问题，则不会影响其他所有客户端。

如果要在客户端之间比较数据，则应分开进行。

如果您的数据库已用尽，则可能应该考虑更改主机提供程序。

我不会为每个客户端提供单独的数据库的唯一原因是，如果您要拥有100或1000个客户端/数据库。这可能非常麻烦，包括更改数据库或在所有数据库中执行某些操作。当您需要打开（并关闭）这么多的表时，在大量的多个数据库中发生的操作也可能很慢。

但是除了这种情况，我认为多个数据库更好。

一个优点可能并不重要，但可能有用，它的一个优点是每个客户端都有自己的顺序ID（而不是因为另一个客户端添加了记录而跳过了一堆）。

而且，多个数据库允许每个客户轻松定制子表（如电话类型），而无需这些表中的父记录ID。

首先，工件排序。我假设您使用整数主键来提供此功能。确实，您应该有一个单独的“工件编号”列。PK应该是PK，无其他。人们谈论“自然键”之类的东西，我感到畏缩。每当您依靠PK不仅仅是一个标识符时，它都会再次咬住您。如果您想知道某物的顺序，请存储一个日期或一个顺序号。

我认为在您的情况下，配置管理会将您带到一个数据库。查看及时维护和升级数据库所花费的成本。每次发布该软件需要支付哪些费用？还需要考虑新客户并必须创建数据库并为其配置应用程序时的成本。一切都可以自动化，问题是，当您有100个数据库时，这是否值得？

在将来，单个数据库的扩展（分区，硬件，分片等）比对100个数据库进行扩展更容易。

我认为其他海报提出了一些出色的观点，所以我不会再赘述了。

要添加到到目前为止的专业人士的名单：

多个数据库的专业版：

1. 避免锁定问题；我们有一些数据库，客户可以在其中触发某些表的DDL更改。对于较大的表（> 2m条记录），这会将表锁定相当长的时间。唯一处于不利地位的人是他们自己的用户，因此这是可以接受的。

2. 灵活性-一些客户对他们希望存储的数据有特定的愿望；多个数据库使我们能够灵活地专门更改其数据库，而不必为其他客户端弄乱数据模型。

缺点：

1. 主要缺点：加入其他表比较麻烦。我们有一个Main数据库，其中包含大多数元数据。特定于客户端的数据库用户无权访问此数据库，因此该数据库中的表与特定于客户端的表之间的所有联接都在应用程序而不是数据库中进行处理。您可以通过为特定于客户端的用户授予对主数据库的访问权限来解决此问题，但是该应用程序可能/可能再次泄漏信息。

祝您好运！

我知道您已经选择了答案，但是似乎没有提出其他解决方案：

将所有内容移至一个数据库，但使用前缀为每个客户创建表，如下所示：

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

这是两全其美的。

• 从当前设置迁移到新设置非常容易。
• 您可以为每个客户创建1个用户，并将其权限限制在其公司的表中，而没有其他权限
• 您可以创建超级用户，并在需要时轻松聚合数据。
• 仅使用一个数据库