it-swarm.cn

单V / s多个数据库

我已经构建了这个Web应用程序(php和mysql),它存储了各种组织的信息(目前约有20个客户)。

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

这里的一个主要优点是,当每个客户端数据库被隔离时,客户端工件(报告,审计)等的编号被排序;给我们的客户一种安全感。

每个数据库大约有15个表,表中的大多数行大约为2000.预计最多可以达到5000个记录。

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

我们正在共享主机安排,我们的ISP为我们提供有限的号码。数据库;这就是我在集中数据库方面的思考;这样所有客户端数据都可以存储在master数据库中。

当然,出现的一些重要问题是:

一个。维护工件序列(可以通过创建附加的引用键来解决)b。速度和性能(在这种情况下,我可以创建索引来加快速度)c。安全性:这将作为每个获取客户端信息的查询进行管理。还会跟踪他们的client_id

将来,我们可能需要考虑将一个组织的数据集与另一个组织的数据集进行比较,但我相信这也可以在集中式数据库上实现。我有点倾向于(出于性能和可维护性的原因)迁移到集中式数据库。

您是否认为迁移到集中式数据库比保持原样(在单个数据库上)更有意义?

谢谢你的建议。

17
Narayan

这两个系统都存在继承风险和回报。我在一家金融公司工作,在一个数据库上支持大约40个客户(国家银行)。然后,我们购买了另一家销售类似软件的公司,并且每个客户都使用了1个数据库。最后,该公司破产了,我们确实必须导出所有用户数据。以下是我与之合作过的人,我发现:

单个数据库的专业版:

  1. 软件更新和错误修复更容易。
  2. 易于管理和报告所有客户数据。
  3. 更新数据变得更容易。
  4. 轻松创建1个客户想要的模块化功能,为其他客户关闭,然后在将来需要时将其打开。

单个数据库的Con:

  1. 数据完整性 - 我们有2或3个案例,其中1个银行的用户看到了另一家银行的数据。这是一场噩梦。特别是因为网站用户不仅仅是银行员工,而是持有银行客户的实际账户!到目前为止,这是1个数据库的最大问题
  2. 导出客户数据 - 当我们不得不这样做时,它通常不是什么大问题。最终得到一个包含所有客户端的表,并关闭该表以获取客户端特定数据。

多个DB的Pro:

  1. 无需担心跨客户数据污染或违规行为
  2. 导出客户数据非常容易。

多个数据库的组成部分:

  1. 更新和错误修复 - 这是真正的噩梦。当您在20个不同的数据库上有20个客户端时,您很快就遇到了一个客户希望修复错误并且另一个认为该错误是一个功能或不想冒更新风险的情况。此外,您将有一个实例,其中一个客户希望游戏改变增强,但其他客户不希望。当发生这种情况时,您的数据库将开始分歧。突然之间,您将需要更新客户端1-15,其中一个脚本16-19与另一个脚本,以及20和第三个脚本。我们看到这个问题变成了这样一个问题:对于我们购买的公司而言,错误修复将花费15到20倍,因为他们必须为每个客户运行所有测试并处理每个客户的特殊代码。实际上,他们需要为每个新客户提供新的支持人员,而母公司需要为每5到10个客户提供一个支持人员。
  2. 数据库管理 - 当您到达大量客户端时,管理所有数据库变得非常麻烦。毫无疑问,您需要更多的DBA时间来管理它们。

最后,我看到并完成两项工作的建议就是“纪律”!我认为多数据库的选择略胜一筹,因为它可以保护你,但是你不能让客户做出让你只为它们添加功能的选择,否则你就会让自己陷入失败之路。

13
Ben Hoffman

我为不同的客户提供单独的数据库。出于安全原因,客户可能会要求这样做 - 即只有他们的站点才能访问他们的数据。这也意味着如果客户想要移动他们的数据,那么它将更容易管理。

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

如果要比较客户端之间的数据,则应单独执行此操作。

如果您的数据库用完了,那么也许您应该考虑更改主机提供程序。

13
ChrisF

要添加到目前列出的专业人士/骗局:

多个数据库的专业版:

  1. 避免锁定问题;我们有数据库,客户端可以在某些表上触发DDL更改。对于较大的表(> 2m记录),这会将表锁定相当长的时间。唯一处于劣势的人是他们自己的用户,所以这是可以接受的。

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

缺点:

  1. 主要骗局:加入其他桌面更加繁琐。我们有一个包含大多数元数据的主数据库。特定于客户端的数据库用户无权访问此数据库,因此该数据库中的表与特定于客户端的表之间的所有联接都在应用程序中而不是在数据库中处理。您可以通过为特定于客户端的用户提供对主数据库的访问来解决此问题,但随后应用程序可能/可能会再次泄漏信息。

祝你好运!

0
kander

我知道你已经选择了一个答案,但看起来还有另外一个没有建议的解决方案:

将所有内容移动到一个数据库,但使用前缀为每个客户创建表,如下所示:

initec_contacts_tbl
initec_accounts_tbl
initec_personel_tbl
...
masterco_contacts_tbl
masterco_accounts_tbl
masterco_personel_tbl

这是两全其美的。

  • 从当前设置迁移到新设置非常容易。
  • 您可以为每个客户端创建1个用户,并将其权限限制在其公司的表中,而不是其他任何内容
  • 如果需要,您可以创建超级用户并轻松聚合数据。
  • 仅使用一个数据库
0
Sylver

我没有为每个客户提供单独数据库的唯一原因是,如果您将拥有100或1000个客户端/数据库。这可能会变得非常毛茸茸,包括进行数据库更改或在所有数据库中执行某些操作。大量多个数据库中发生的操作也可能很慢,因为您需要打开(因此关闭)这么多表。

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

一个可能不重要但可能有用的优点是每个客户端获取自己的顺序ID(而不是可能跳过一堆,因为另一个客户端添加了记录)。

此外,多个数据库允许每个客户端轻松自定义子表(如电话类型),而无需在这些表中使用父记录ID。

0
Darryl Hein

首先是人工测序。我假设您使用整数主键来提供此功能。真的,你应该有一个单独的“工件编号”列。 PK应该是PK而不是别的。人们谈论“自然键”之类的东西,我感到畏缩。每当你依赖PK不仅仅是一个标识符时,它就会回来咬你。如果您想知道存储日期或序列号的某些事物的顺序。

我认为在您的情况下,配置管理会将您带到一个数据库。查看维护和升级数据库所花费的时间。与软件的每个版本相关的成本是多少?还要考虑获得新客户时的成本,并且必须创建数据库并为其配置应用程序。任何东西都可以自动化,问题是,当你拥有100个数据库时,它是否值得?

在未来的道路上,单个数据库的扩展(分区,硬件,分片等)比100个数据库的扩展更容易。

我认为其他海报已经取得了一些优点,所以我不会过去那些。

0
Gareth Farrington