用户数据的数据库设计

Question

我正处于新项目的早期阶段。由于我们正在迭代且相对快速地开发（随着我们的设计而设计产品），有时候为某些事情选择“正确”的设计可能会有点困难。我们倾向于选择一些东西并在必要时重新考虑因素。

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

这使我们能够在早期阶段非常灵活地处理我们与用户存储的数据。如果我们不需要对数据进行复杂的查询（我们还没有），这可以实现良好的可扩展性。

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

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

Answer 1

正如你自己说的那样：

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

因此，只要您需要“复杂”查询，无论是经过时间还是正确编写查询所需的时间，这都会变得效率低下。

也许你可以接近这个零碎的方法，并且只要一个特定的子集“在野外”使用足以保证其稳定，就可以将一些键值对迁移到实际的表字段中？

一般来说，关系模型有其优势，管理大量键值“伪域”并不是其中之一。为此，您可能想要使用NOSQL产品。

Answer 2

您应该问的问题是：

• 我们可以在设计应用程序时预测所有密钥吗？
• 我们的应用程序是否以不同的方式处理不同的密钥（即您的代码中是否有if (Key=="something")的等价物？）

如果您可以提前为所有可能的密钥设计应用程序，并且您的应用程序正在以特定方式处理它们，您应该只在“主”表中添加适当的列并完全停止使用“键值”表

如果您可以预测所有按键，但是您可以一般地处理其中的一些按键，您可以保留您的结构，或者您可以将您特别处理的那些按键移动到“主”表的列中，并将其余按键保留在“键”中价值“表。

如果您无法预测所有可能的密钥（即用户将能够添加自己的密钥），即使您可以使用通用方式处理这些密钥，请保留当前结构。