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

流年物语

我使用PHP和mySQL。
我有一个页表和一个元表。看起来有点像这样。
页表
page_id | headline    | content
--------------------------
1       | My headline | My content
& T/ o7 Y2 m8 Y/ x8 Y. |2       | Another one | Another text
元表
: Y% ?' X6 Q5 D& R% oid | page_id | meta_key  | meta_value
3 W; [$ h1 ^2 ]------------------------------------
1  | 2       | seo_title | Hello world
2  | 2       | price     | 299
我已经读过这种类型的模型称为EAV。我还读到它对性能不利。
我的元表用于连接到页面的任何类型的值。这次我无法创建带有“静态”列的表。
问题
" B5 H8 G4 b# B  `这对于300页（每页上都有30个元值）有多严重？元表中有9000行。
) v# T$ C. x3 l. e& ~是否有更好的“动态”数据模型？

               
解决方案:
: p. I& J' G, F) x* b5 h. j               


' c( L1 s4 C! B                首先
，有时该模型使查询数据变得更加容易。几天前，我问了一个问题，一些用户提出了为什么我不将模型更改为1NF形式以使查询数据更容易的问题。只有当他们意识到我对这种设计感到困惑时，他们才提供了该问题的一些答案。关键是我很幸运只有12列可以总结。否则，如果我的表包含300列，那么也许没有用户会费心地为该问题编写查询。:-)
其次
，由于数据库自然施加的某些限制，有时该设计的实现更容易。如果您的meta_key值包含一些大于30个字符的冗长值，则您必须缩短值并在某处进行映射，否则这可能是您唯一的选择。
6 e7 p3 |; w( y7 ~7 O5 x% d# l最后 ，性能非常重要。确实如此。但是，另一方面，您可以应用某些技术来提高性能。例如通过创建适当的索引，对表进行分区等。
. Z9 F( z, I0 B( J9 T% m在这种情况下，表的大小非常小。因此，除非您的查询非常复杂（例如具有大量计算以及复杂的联接和聚合），并且如果应用程序对较小的时间间隔不敏感，那么我猜如果采用此模型，您的性能将不会受到影响。
最后 ，如果您仍然过于关注性能，建议您创建两个模型，并用一些随机或真实数据填充它们，并分析计划成本，以查看哪种模型更适合您的需求。