1

我正在构建一个应用程序，其中几个组织可以注册自己并操作一组企业表，例如客户列表、卖家、项目、销售订单等...我想知道是否与其拥有一组表，不如为每个客户端拥有一组单独的表会更安全，所有表都在同一个数据库中运行。例如，数据库可能具有以下架构：

JOHNDOEFIRM_CUSTOMERS
JOHNDOEFIRM_CLIENTS
JOHNDOEFIRM_ORDERS
...

JAKEDOESONFIRM_CUSTOMERS
JAKEDOESONFIRM_CLIENTS
JAKEDOESONFIRM_ORDERS
...

依此类推，每个公司都有一组表格。每次公司注册时都会创建这些表，并带有适当的前缀。这可能具有以下优点：

  1. 如果一家公司不能不小心弄乱另一家公司的桌子会更安全
  2. 将对表进行特定于公司的定制

与为每家公司完全保留一个单独的数据库相比，这样做有什么优势？由于每个公司将有大约 20-40 个表，表的数量是否会随着用户数量的增加而呈爆炸式增长，从而完全减慢数据库的速度？

非常欢迎对刚才描述的应用程序设计的任何反馈以及我在这篇文章中指出的问题以及注意事项的建议。

谢谢。

4

2 回答 2

2

我想知道是否不是拥有一组表，而是为每个客户端拥有一组单独的表会更安全，所有表都在同一个数据库中运行。

如果您想这样做，您可以为每个客户端设置一组单独的表，在不同的逻辑数据库中运行。DBA 更容易管理。

您基本上承认，在共享相同的数据库表时，您不能依赖应用程序代码来保持公司分开。

由于每个公司将有大约 20-40 个表，表的数量是否会随着用户数量的增加而呈爆炸式增长，从而完全减慢数据库的速度？

您要么为每个公司拥有 20 - 40 张桌子，要么为所有公司拥有 20 - 40 张大桌子。无论哪种方式，存储量都将大致相同。

如果每个公司都有自己的逻辑数据库，那么 DBA 可以灵活地将公司迁移到新的物理数据库。假设您可以将 5 家公司的表放在服务器上。换句话说，每个物理数据库有 5 个逻辑数据库。然后您的 DBA 知道要管理多少台服务器。

如果某个特定的公司导致更多的数据库问题，那么该公司的逻辑数据库可以移动到它自己的物理数据库中，直到问题得到解决。

于 2013-06-03T15:00:48.043 回答
1

您描述的问题通常称为“多租户架构”。没有正确或错误的答案 - 但有一大堆权衡。

您的设计 - 每个客户端的表命名空间 - 具有您提到的好处。每个客户端都有自己的隔离表集，因此任何一个客户端都很难影响另一个客户端的数据，您可以将不同的版本应用于不同的客户端。缺点是相当可怕的——每次更改应用程序时，最终都会更改数百个客户的表。如果您有共同的数据 - 货币、世界国家、大小 - 您必须在客户端之间复制这些数据 (JOHNDOE_COUNTRIES)，或者有一个打破“John Doe 的所有表格都称为 JOHNDOE_”的一致性。单个错误（尤其是查询中的性能问题）会随着您拥有的客户端数量而变化，并且必须针对每个客户端进行修复。在您的应用程序代码中，

这里提到的替代选项 - 每个客户端的数据库 - 更加优雅。您保持客户端之间的分离，您可以将不同的客户端放在不同的物理硬件上以管理性能/可扩展性，您不必在应用程序代码中破坏表名，并且您的构建/部署脚本要简单得多。但是，您仍然有整个“为每个客户更改一次相同的代码”的问题。它很快就变成了一个问题——如果你的构建/部署脚本需要 10 分钟，那么当你有 200 个客户端时，升级你的应用程序需要一整天的时间。

当然，您可以将 client_id 烘焙到数据库模式中 - 将 CLIENT_ID 作为 CLIENTS、ORDERS 等中的列。这意味着代码中的错误意味着一个客户端可以影响另一个客户端的数据——但这种可能性仍然存在于另一个情景。例如，在选项一中破坏表名的代码可能包含选择错误客户端前缀的错误。

但是，具有大量 client_id 的单个大型数据库来识别哪个客户端“拥有”数据更容易管理 - 单个构建/部署脚本，修复和测试错误可以只发生一次，新功能只推出一次。这种成本节约可能是巨大的。

因此，我的建议是从一个带有 CLIENT_ID 的数据库开始，但可以选择为每个客户端选择不同的数据库，以便将来可以扩展到多个数据库。我不会为每个客户使用不同的表。

于 2013-06-03T16:50:47.617 回答