我使用PHP和mySQL。
我有一个页表和一个元表。它看起来有点像这样。
Page table
page_id | headline | content
--------------------------
1 | My headline | My content
2 | Another one | Another text
元表格
id | page_id | meta_key | meta_value
------------------------------------
1 | 2 | seo_title | Hello world
2 | 2 | price | 299
我读过这种类型的模型叫做EAV。我还读到它是bad for performance。
我的元表适用于连接到页面的任何类型的值。我这次不能用“静态”列创建一个表。
问题
答案 0 :(得分：2)
首先，有时此模型可以更轻松地查询数据。几天前我问过一个问题here，有些用户建议我为什么不将我的模型更改为1NF表单以使查询数据更容易。只有当他们意识到我被这个设计困住时，他们才提供了一些问题的答案。关键是我很幸运，只有12列可以总结;否则，如果我的表包含300列，也许没有用户打扰自己为该问题编写查询。 ： - ）
第二，由于数据库自然会施加一些限制，有时这种设计的实施会更容易。如果您的meta_key值包含一些大于30个字符的冗长值，则您必须缩短值并在某处进行映射，否则这可能是您可能拥有的唯一选项。
最后，表现非常重要;确实如此。但是，另一方面，您可以应用某些技术来提高性能;例如，通过创建适当的索引，分区表等。
在这种情况下，表格尺寸非常小。因此，除非您的查询非常复杂，例如计算量大，连接和聚合复杂，并且如果应用程序对小时间分数不敏感，我想如果采用此模型，您将不会受到性能影响。
最后，如果您仍然过于关注性能，我建议创建两个模型，用一些随机或真实数据填充它们，并分析计划成本以查看模型更适合您的需求。
答案 1 :(得分：1)
规范化的数据库模式基本上针对一般情况进行了优化。与之相比，高度非规范化的模式对性能不利。
但这实际上意味着什么取决于您的用例。你在运行什么问题？所以我建议如下：
确保将完整的持久层与其他所有内容完全分开。
确保自动测试包括性能测试。
实施您当前的解决方案，从创建最复杂的性能关键查询的部分开始。不要在这一步投入太多。可能低于项目预算的5％。
检查表现是否足够。
如果检查失败，您有以下选项：
添加物化视图
使用更适合工作的替代系统。密钥值存储可能就是您要找的东西。
或者您可能需要一种混合方法：应用程序的一部分使用EAV，使用其他更适合查询的方法复制数据。