单个V / s多个数据库

#1 楼

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

单个DB的专业版：


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

单一数据库的缺点：


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

多个DB的专业版：


不必担心跨客户端数据受到污染或破坏
导出客户端数据非常容易。

多个DB的缺点：


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

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

#2 楼

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

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

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

如果用尽了数据库，那么也许应该正在考虑更改您的主机提供商。

#3 楼

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

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

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

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

#4 楼

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

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

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

我认为其他张贴者也提出了一些很好的观点，所以我不再赘述。

#5 楼

要添加到到目前为止的专业人士列表中，请：

多个数据库的专业人士：


避免了锁定问题；我们有数据库，客户可以在其中触发某些表的DDL更改。对于较大的表（> 2m条记录），这会将表锁定相当长的时间。唯一处于不利地位的人是他们自己的用户，因此这是可以接受的。
灵活性-一些客户对他们希望存储的数据有特定的愿望；多数据库使我们可以灵活地专门更改其数据库，而不必为其他客户端弄乱数据模型。




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

选择时很幸运！

#6 楼

我知道您已经选择了一个答案，但似乎并没有建议其他解决方案：

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

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

两全其美。


很容易从您的当前设置迁移到新设置。
您可以为每个客户创建1个用户，并
将其特权限制在其公司的表中
，并且没有其他
您可以创建超级用户并轻松聚合数据（如果需要）因此。
仅使用一个数据库