数据库设计麻烦。每个用户的表格

Question

首先，我知道在stackoverflow上讨论here和here的问题。但是这种情况可能会有所不同。

让我解释一下这种情况：

老板叫我和我的同事开发一个Web应用程序，在那里他可以增加客户（读公司，现在的形式对“用户”）。
每个用户在应用程序中都有自己的专用部分，他可以管理他的库存/结算/付款/订单/ ...他们甚至可以选择为他们的私人提供不同的模块/菜单项/视图/ ..部分。
我们的老板必须能够通过检查主控部分中的选项来添加/删除一些模块/视图/ ..
依此类推......

我首先想到的是每个用户都有一个主模块。这个想法被我的同事抛弃了。他认为这太过分了。
但是，当我们开始设计数据库时，他说他想为每个用户在数据库中拥有大多数表格......
我知道这是不好的做法并试图解释。 但他表示，如果我们将所有内容都保存在同一张表中，那将是不安全的。 （如果我们被黑客攻击，他们不仅会有一家公司的数据，但来自所有公司的数据）
讨论需要一段时间，最终他的'''''''甚至让我们的老板相信他的方法。

由于我这里是新来的家伙，我不喜欢站在这家公司没有肯定知道如果his statement === false

所以，我会爱你的这个意见。

• 如何安全
• 如何个性化每家公司
• 如何管理数据库
• 是否有任何人谁也有类似的项目
• 如何使用不同的“模块”为每公司（在我的第一个想法）
• ...（实际上所有的信息说服他们都很好，但我觉得我必须来与一个很好的选择）

在此先感谢

Answer 1

这在一定程度上个人oppinion的问题。但有些事情不是很好的做法。所以这里是我对这些观点的看法：

在同一个表中有多个“用户”根本不应该是安全风险。

• 如果有人有权访问你的数据库，他拥有所有的数据，不管存储在哪里。
• 您的应用必须通过筛选和验证的WHERE条件来确保用户无论如何都只能访问其行，否则您的应用将在其他级别的SQL注入中遇到严重的安全问题
• 如果每个用户有一张表，在将应用扩展到新用户，管理旧用户或将其删除时，您将遇到很多麻烦。
• 如果您需要从多个用户收集数据，性能将会非常差
• 根据许多因素，大多数DB中有最大数量的表。我不知道你将有多少用户存储，但保持这种一记

用户分隔条件的到自己的表中的解决方案听起来像你跳过，奠定坚实和安全的数据模型所需要的时间。这通常会在后期开发或维护应用程序时导致很多问题。我强烈反对这个建议。

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