我正处于一个新项目的早期阶段。由于我们正在进行迭代和相对快速的设计（我们正在设计产品），有时候可能有点难以为事前选择“正确”的设计。我们倾向于选择一些东西，并在必要时重新考虑因素。用户数据的数据库设计
现在我正在处理用户数据的模型。我的方法是基本上有两个表：一个具有基本登录类型数据（用户名，创建日期，凭证等），另一个表用于存储我们需要与用户关联的Key，Value数据。
这使我们可以在早期阶段非常灵活地了解我们与用户存储什么数据。假如我们不需要对数据进行复杂的查询（我们现在还没有），这就提供了良好的可扩展性。
这也是我之前使用的一种模式。
我的一个大问题是，为什么从长远来看这是一个糟糕的设计？
你应该问的问题是：
if (Key=="something")）？如果您可以预先为所有可能的键设计您的应用程序，并且您的应用程序正在以特定方式处理它们，那么您应该在“主”表中添加适当的列并停止使用“键值“表格。
如果您可以预测所有按键，但是您可以对其中一些按键进行一般处理，您可以保留自己的结构，或者将特殊对待的按键移动到“主”表的列中，并将其余按键放在“按键值“表。
如果无法预测所有可能的键（即用户将有能力添加自己的键），甚至可以以通用方式处理这些键，请保留当前结构。
正如你自己说：
“只要我们不需要对数据复杂的查询（我们暂时不具备），这使得良好的扩展性”
因此，只要您需要“复杂”的查询，这将变得效率低下，无论是在经过的时间，以及正确编写查询本身所需的时间。
也许你可以接近零碎，并且一旦给定的子集“在野外”使用足以保证它的稳定性，就可以将一些键值对迁移到实际的表字段中。
一般来说，关系模型有其优势，而管理大量关键值“伪字段”并不是其中之一。为此你可能想要去NOSQL产品。