我目前正在重新设计一个可能包含大量数据的数据库 - 我可以选择在数据库中包含许多不同的列或使用大量行。如果我在下面做一些大纲,可能会更容易:
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 中,我如何将多行转换为可用的列格式(我猜是临时表)——例如,我可以按内容类型进行一些过滤。
基本上,只要不改变每个表级别的行长度,mysql 就有可变的行长度。因此,空列不会使用任何空间(好吧,几乎)。
但对于 blob 或文本列,最好对它们进行规范化,因为它们可能需要存储大量数据,并且每次扫描表时都需要读取/跳过这些数据。即使该列不在结果集中,并且您在索引之外执行查询,也将花费时间处理大量行。
作为一种良好的做法,我认为将所有管理和常用的列放在一个表中并标准化所有其余的会很快。第二个示例中的“垂直”设计阅读起来很复杂,一旦您使用临时表,您迟早会遇到性能问题。
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)