我正在重新设计一个可能包含大量数据的数据库 - 我可以选择在数据库中包含许多不同的列，也可以使用大量的行。如果我在下面做了某种大纲，可能会更容易：
item_id | user_id | title | description | content | category | template | comments | status
-------------------------------------------------------------------------------------------
1 | 1 | ABC | DEF | GHI | 1 | default | 1 | 1
2 | 1 | ZYX | | QWE | 2 | default | 0 | 1
3 | 1 | A | | RTY | 2 | default | 0 | 0
4 | 2 | ABC | DEF | GHI | 3 | custom | 1 | 1
5 | 2 | CBA | | GHI | 3 | custom | 1 | 1
与以下结构中的内容相对应：
item_id | user_id | attribute | value
---------------------------------------
1 | 1 | title | ABC
1 | 1 | description | DEF
1 | 1 | content | GHI
... | ... | ... | ...
我可能希望将来创建其他属性（参数为50） - 因此如果使用多列，可能会有很多空单元格。在可能的情况下，属性名称将在不同类型的内容中重复使用 - 例如博客条目，事件和图库 - title可以轻松重复使用。
所以我的问题是，在查询速度和磁盘空间方面，使用多列还是多行更有效。或者你会建议关系表，所以有一个博客表，一个事件表等等。我只是想提出一个易于扩展的解决方案，我理想情况下不想为每种类型创建一个表内容，因为我正在考虑开发人员通过app / API系统创建新类型的内容（属性受到严格控制）。
多行的补充问题
我怎样才能在MySQL中将多行转换为可用的列格式（我猜临时表） - 所以我可以按内容类型进行一些过滤，作为一个例子。
答案 0 :(得分：2)
基本上，mysql具有可变的行长度，只要一个不改变每个表级别。因此，空cols不会使用任何空间（好吧，差不多）。
但是对于blob或文本列，最好对这些列进行规范化，因为这些可能需要存储大量数据，并且每次扫描表时都需要读取/跳过这些数据。即使列不在结果集中，并且您在索引之外进行查询，也会占用大量行的时间。
作为一种良好的做法，我认为将所有管理和经常使用的cols放在一个表中并将所有其余的归一化是很快的。第二个示例中的一种“垂直”设计将很复杂，一旦您使用临时表，您迟早会遇到性能问题。
答案 1 :(得分：1)
对于传统的基于行的存储，通过行进行假脱机的成本取决于它们的宽度，因此扫描具有宽行的表将花费比具有窄行的表更长的时间。
那就是说，你正在使用索引来定位感兴趣的行，这不会是一个很大的问题。
如果通过用其他表中的行替换列来规范化数据，如果链接表最终明显小于原始表，则可以减少存储量，但是任何查询都需要包含需要加入相关表格。
与所有这些事情一样，这是一种取决于您的要求的平衡行为，但了解幕后发生的事情当然可以帮助您做出更明智的决策。
答案 2 :(得分：1)