Php 数据库设计问题。每个用户的表

首先，我知道这个问题已经讨论过了，而且是关于stackoverflow的。然而，这种情况可能有所不同

让我解释一下情况：

老板希望我和我的同事开发一个web应用程序，他可以在其中添加客户（阅读公司，现在在“用户”上填写表单）。
每个用户在应用程序中都有自己的私有部分，在那里他可以管理自己的股票/账单/付款/订单/。。。他们甚至可以选择询问不同的模块/菜单项/视图/。。他们的私人部分。
我们的老板必须能够添加/删除一些模块/视图/。。通过选中主控制部分中的选项。
等等

我的第一个想法是为每个用户提供一个主模块。这个想法被我的同事抛弃了。他认为这太过分了。
但是，当我们开始设计数据库时，他说他希望在数据库中为每个用户提供大多数表…
我知道这是不好的做法，并试图解释但是，他表示，如果我们将所有内容保存在同一个表中，则不安全。（如果我们被黑客攻击，他们不仅拥有一家公司的数据，而且还拥有所有公司的数据）
讨论花了一些时间，最后他的“观点”甚至让我们的老板相信了他的方法

因为我是这里的新人，我不喜欢在没有确定的情况下坚定立场如果

他的陈述===false

所以，我想听听你对这件事的看法

• 保安怎么样
• 每个公司的个性化设置如何
• 管理数据库怎么样
• 有没有人有过类似的项目
• 对每家公司使用不同的“模块”怎么样（如我的第一个想法）
• 。。。（事实上，说服他们的所有信息都很好，但我觉得我必须提供一个很好的替代方案）

---

提前感谢

这在某种程度上是个人机会的问题。但有些事情并不是好的做法。以下是我对这些观点的看法：

在同一个表中有多个“用户”不应构成任何安全风险

• 如果有人可以访问您的数据库，则他拥有所有数据，无论存储在何处
• 您的应用程序必须通过过滤和验证确保用户只能以任何方式访问其行，否则您的应用程序将在SQL注入之前的其他级别上存在严重的安全问题
• 如果每个用户都有一个表，那么在将应用程序扩展到新用户、管理旧用户或删除旧用户时就会遇到很多麻烦
• 如果必须从多个用户收集数据，性能将非常差
• 在大多数数据库中，表的数量是最大的，这取决于许多因素。我不知道你需要存储多少用户，但请记住这一点

将用户分离到他们自己的表中的解决方案听起来像是在跳过开发可靠安全的数据模型所需的时间。在应用程序的后期开发或维护过程中，这通常会导致许多问题。我强烈反对这样做

---

经验法则应该是每个对象类型使用一个表，而不是每个对象实体使用一个表。

所以让我弄清楚，每个用户都应该有自己的一对相等的表来存储数据，通常可以存储在表上，每行用一个用户ID来区分。我不明白为什么有更多的表会更安全。如果你被黑客攻击了，整个数据库将为黑客提供每个表。这对我来说似乎毫无意义。对我来说，这听起来像是维护性的噩梦。。。每一个小小的更改都必须应用于每个用户表。我不知道安全性问题，但我想如果有人能够设法破坏一个表，他可能也会破坏整个数据库。从数据库设计的角度来看，这听起来是错误的。在DB设计级别上，安全性不应该是（这么大的）一部分。由应用程序层来确保与数据库的安全通信。这将是一个糟糕的数据库设计。从维护的角度来看，如果您决定将一列添加到用户的表中，则必须将其添加到所有用户的表中。使用安全性作为这种糟糕设计的借口并不是一个有效的论据——一般来说，如果你被黑客攻击，整个数据库都会被破坏。这是一个很棒的应用程序设计师，让所有用户都拥有自己的表，当project陷入如此混乱以至于没有任何东西可以挽救它时，就换一份新工作吧！有些人应该被禁止在里面做任何事情。谢谢你的观点。如果您只需要为某些“用户”添加字段，情况如何。由于这是我的同事关心的问题，我想知道如何为他们提供解决方案that@Brainfeeder如果您想为每个用户提供不同的字段/选项/条目，或者您只是想提供这样做的可能性，那么您应该将这些内容抽象到另一个相关的表/数据模型中，例如，用户表用户选项表这也是我的建议。制作一个userid/key/value表，你可以存储任何你想要的属性。这些表格也可以通过几个属性轻松搜索。唯一的缺点是您必须自己透视（收集每个用户的所有属性），因为大多数SQL表都没有用于透视的方法。如果您自己进行数据透视，请使用PHP而不是DB。PHP的数组函数速度非常快。@Brainfeeder——在Quasadunk和ToBe所说的基础上——研究EAV（实体属性值），这是您在数据库中存储用户特定值的模型（它由ToBe解释的实体组成）。回答不错——但不同意您的第二个要点（与第一个要点相矛盾）-如果您的应用程序易受SQL注入攻击，则每个用户的表要具有任何优势，还需要其他几个先决条件。还有一点是，多表方法增加了很多复杂性