对于以下情况，我应该采用两种数据库模式方法中的哪一种感到困惑。
我需要为网站存储多个属性，例如页面大小、字数、类别等以及将来可能会增加属性数量的地方。目的是向用户显示此表，他应该能够在数据中快速过滤/排序(因此表结构应支持快速查询和排序)。我还想保留以前数据的日志以维护更改时间表。所以我想到的两种表结构方案是:
选项 A
网站属性
id, website_id, page_size, word_count, category_id, title_id, ......(最多 18 列并且必须记住可能有一些空值并且可能还需要在中添加更多列 future )
website_attributes_change_log
与上面相同的表结构，添加了“change_update_time”列
我觉得这种模式的优点是即使某些属性链接到其他表，查询也很容易编写，而且排序也很简单。我猜想稍后添加列的缺点可能会出现问题，因为 ALTER TABLE 需要很长时间才能在大型数据表上运行 + 可能有很多行包含许多空列。
选项 B
网站属性字段
attribute_id、attribute_name(例如 page_size)、attribute_value_type(例如 int)
网站属性
id, website_id, attribute_id, attribute_value, last_update_time
这里的优势似乎是这种方法的灵 active ，因为我可以随时添加列，而且还可以节省存储空间。然而，尽管我很想采用这种方法，但我觉得在需要显示表格时编写查询会特别复杂[因为我需要一次显示多个站点的记录并且还会有交叉引用某些属性的值与其他表的值] + 对数据进行排序可能很困难 [鉴于这不是基于列的方法]。
我要查看的示例输出是:
Site-A.com，232032 字节，232 个字，PR 4，房地产 [链接到类别表]，..
Site-B.com, ..., ..., ... ,...
并且用户需要能够按所有基于数字的列进行排序，在这种情况下，方法 B 可能会很困难。
所以我想知道我选择选项 A 是否是正确的选择，或者是否还有其他更好的选择，我可能一开始就没有考虑过。
最佳答案
我建议使用选项 A。
您可以使用 pt-online-schema-change 减轻长时间运行 ALTER TABLE 带来的痛苦.
即将推出的 MySQL 5.6 支持 non-blocking ALTER TABLE操作。
选项 B 称为 Entity-Attribute-Value , 或 EAV。这打破了关系数据库设计的规则，因此针对这种格式的数据编写 SQL 查询肯定会很尴尬。你可能会 regret using it .
我有posted several times on Stack Overflow描述 EAV 的缺陷。
同样在我的博客中:EAV FAIL .
关于mysql - 这两种 MySQL DB Schema 方法中的哪一种对于检索和排序最有效？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13717918/