列数太多了多少列？

Question

我注意到这里有很多人在一个表中列出了20多个(我已经看到多达55个)列的表.现在我不假装成为数据库设计专家,但我总是听说这是一个可怕的做法.当我看到这一点时,我通常建议分成两个具有一对一关系的表:一个包含最常用的数据,另一个包含最少使用的数据.虽然同时存在性能问题(更少的JOIN等).所以我的问题是:

当谈到真正的大规模数据库时,拥有大量列实际上是否有优势,尽管这通常导致许多NULL值？

这更像是一个性能损失:很多列有很多NULL,或者有很多JOIN的列？

Answer 1

表的设计取决于它需要存储的实体.如果所有数据都属于一起,则50列(甚至100)可能是正确的.

只要表格被规范化,除了数据库功能和优化需求之外,没有关于大小的经验法则.

Answer 2

我同意Oded的观点.我看过其中有500列的表格,其中的所有列都在正确的位置.只考虑一个人可能希望存储的关于日常物品的事实数量,你很快就会明白为什么.

如果证明选择所有这些列不方便,或者当您只对其中的一小部分感兴趣时指定要选择哪些列,您可能会发现定义视图是值得的.

Answer 3

列数太多了多少列？

当你觉得它不再有意义或者添加另一列时是正确的.

一般取决于应用.

Answer 4

有太多的列会导致很多空值（邪恶）和表映射到的笨重对象。这会损害 IDE 的可读性并阻碍维护（增加开发成本）。如果您在某些情况下需要快速读取，请使用非规范化表，例如仅用于报告或查询（搜索“CQRS”模式）。是的，“人”有一百万个属性，但您可以分解这些单块表（设计先于规范化）以匹配较小的实体（“地址”、“电话”、“爱好”），而不是为每个新用例添加新列。拥有较小尺寸的物体（和桌子）带来了很多好处；它们支持单元测试、OOP 和 SOLID 实践等。

此外，关于将大量列聚集在一起以避免连接，我认为避免连接带来的性能增益会通过索引维护而丢失，假设读取和写入的典型工作负载。为了读取性能在字段上添加索引可能表明需要将这些字段移动到它们自己的表中。