Database design 用户数据的数据库设计

我正处于一个新项目的早期阶段。由于我们是迭代开发的，而且开发速度相对较快（边开发边设计产品），所以有时要提前选择“正确”的设计可能会有点困难。我们倾向于选择一些东西，并在必要时重新考虑

现在我正在研究用户数据的模型。我的方法是基本上有两个表：一个表包含基本的登录类型数据（用户名、创建日期、凭据等），另一个表存储我们需要的与用户关联的键、值数据

这使我们能够在早期阶段非常灵活地向用户存储哪些数据。如果我们不需要对数据进行复杂的查询（我们现在还不需要），这就允许了良好的可伸缩性

这也是我以前使用过的模式

我最大的问题是，为什么从长远来看这是一个糟糕的设计？

正如你自己所说：

“如果我们不需要对数据进行复杂的查询（目前还不需要），这就可以实现良好的可扩展性。”

因此，一旦您需要“复杂”查询，这将变得效率低下，无论是在运行时间方面，还是在正确编写查询本身所需的时间方面

也许您可以采用这种分段方式，一旦给定的子集“在野外”使用到足以保证其稳定，就可以将一些键值对迁移到实际的表字段中

---

一般来说，关系模型有其优点，管理大量键值“伪字段”不在其中。为此，您可能想访问NOSQL产品。

您应该问的问题是：

• 在设计应用程序时，我们能预测所有关键点吗
• 我们的应用程序是否对不同的键有不同的处理方式（例如，在代码中的任何地方是否有等价的

  if（Key==“something”）

如果您可以提前为所有可能的键设计应用程序，并且应用程序以特定的方式处理它们，那么您应该只向“main”表添加适当的列，并完全停止使用“key-value”表

如果可以预测所有键，但对其中一些键进行一般处理，则可以保留结构，或者将专门处理的键移动到“main”表的列中，将其余键保留在“key-value”表中

如果您无法预测所有可能的密钥（即用户将能够添加他们自己的密钥），甚至您可以始终以通用方式处理的密钥，请保留当前结构