更高效地拥有更多列或更多行？

Question

我目前正在重新设计一个可能包含大量数据的数据库 - 我可以选择在数据库中包含许多不同的列，也可以使用大量的行。这也可能是更容易，如果我做了某种以下大纲：

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将很容易被重用。

所以我的问题是，使用多列或多行 - 在查询速度和磁盘空间方面效率更高。或者你会推荐关系表，所以有一个博客表，一个事件表等等。我只是试图想出一个易于扩展的解决方案，我最好不想为每种类型的表创建一个表内容，因为我正在考虑开发人员通过应用程序/ API系统创建新类型的内容（属性被严格控制）。

补充问题如果多行

我怎么会在MySQL中，转换多个行到一个可用列格式（我猜的临时表） - 这样我就可以通过内容类型做一些过滤，作为一个例子。

Answer 1

对于传统的基于行的存储，通过行后台处理的成本将取决于其宽度，因此扫描宽行的表会比使用窄行的表更长。

也就是说，它使用索引来定位感兴趣的行，这不会是一个问题。

如果通过用其他表中的行替换列来标准化数据，那么如果链接表最终比原始表小很多，则可以减少存储量，但是任何查询都需要包含成本所需的加入到相关表中。

就像所有这些事情一样，这是一个取决于您的要求的平衡行为，但理解发生了什么事情可以帮助您做出更明智的决定。

Answer 2

基本上，只要不改变每个表的级别，mysql就有一个可变的行长度。因此，空cols不会使用任何空间（好，差不多）。

但是对于斑点或文本列，最好对它们进行规范化处理，因为这些数据可能要存储大量数据，并且每次扫描表时都需要读取/跳过这些数据。即使该列不在结果集中，并且您正在索引之外进行查询，也会花费大量的时间。

作为一种良好的做法，我认为将所有管理和经常使用的列放在一张表中并对所有其他列进行标准化将会很快。第二个示例中的一种“垂直”设计将会非常复杂，只要您使用临时表，您迟早会遇到性能问题。

Answer 3

这个问题很难回答，因为这一切都归结为您正在寻找的内容以及您的数据库随着时间的推移如何在规模和复杂性方面发展。我发现回答这些类型问题的最佳方式是从其他成功网站上阅读案例研究。例如，Reddit将是一个案例研究，他们使用了很多行，但使用了很少的表格和/或列。该文章是here，其上的一个问题是here。

还可以选择探索NoSQL解决方案，该解决方案可能更适用于您试图实现的目标。

谷歌对与您自己的结构类似的网站进行案例研究，看看它们是如何实现的，因为它们很可能遇到了所有您将要并已经克服的问题。