我正处于一个新项目的早期阶段。由于我们正在迭代且相对较快地开发（在进行时设计产品），有时可能会更难为某件事选择“正确”的设计。我们倾向于选择一些东西并在必要时进行重构。
现在我正在研究用户数据模型。我的方法是基本上有 2 个表：一个包含基本登录类型数据（用户名、创建日期、凭据等），另一个表用于存储我们需要与用户关联的 Key、Value 数据。
这使我们能够在早期阶段非常灵活地处理我们与用户存储的数据。假设我们不需要对数据进行复杂的查询（我们现在还不需要），这可以实现良好的可扩展性。
这也是我以前用过的一种模式。
我最大的问题是，为什么从长远来看这是一个糟糕的设计？
【问题讨论】：
标签： database-design entity-attribute-value
你应该问的问题是：
if (Key=="something") 等效的位置）？如果您可以提前为所有可能的键设计应用程序，并且您的应用程序以特定方式处理它们，那么您应该在“主”表中添加适当的列并完全停止使用“键值”表.
如果您可以预测所有键，但您对其中一些键进行通用处理，则可以保留您的结构，或者您可以将您特别处理的键移到“主”表的列中，并将其余键留在“键-值”表。
如果您无法预测所有可能的键（即用户将能够添加自己的键），甚至那些您可以始终以通用方式处理的键，请保留当前结构。
【讨论】：
正如你自己所说：
“如果我们不需要对数据进行复杂的查询（我们现在还不需要），这可以实现良好的可扩展性。”
因此，一旦您需要“复杂”的查询，这将变得低效，无论是在经过的时间方面，还是在正确编写查询本身所需的时间方面。
也许您可以逐步解决这个问题，并在给定子集“在野外”使用足以保证其稳定后立即将一些键值对迁移到实际表字段？
一般来说，关系模型有其优势，管理大量键值“伪字段”不是其中之一。为此，您可能想使用 NOSQL 产品。
【讨论】：