实体属性值模型-性能替代方案？

实体属性值模型-性能替代方案？

首先
，有时该模型使查询数据变得更加容易。几天前，我问了一个问题，一些用户提出了为什么我不将模型更改为1NF形式以使查询数据更容易的问题。只有当他们意识到我对这种设计感到困惑时，他们才提供了该问题的一些答案。关键是我很幸运只有12列可以总结。否则，如果我的表包含300列，那么也许没有用户会费心地为该问题编写查询。:-)

其次
，由于数据库自然施加的某些限制，有时该设计的实现更容易。如果您的

meta_key

值包含一些大于30个字符的冗长值，则您必须缩短值并在某处进行映射，否则这可能是您唯一的选择。

最后 ，性能非常重要。确实如此。但是，另一方面，您可以应用某些技术来提高性能。例如通过创建适当的索引，对表进行分区等。

在这种情况下，表的大小非常小。因此，除非您的查询非常复杂（例如具有大量计算以及复杂的联接和聚合），并且如果应用程序对较小的时间间隔不敏感，那么我猜如果采用此模型，您的性能将不会受到影响。

最后 ，如果您仍然过于关注性能，建议您创建两个模型，并用一些随机或真实数据填充它们，并分析计划成本，以查看哪种模型更适合您的需求。