多少列是太多列？ [关闭]

Posted 2023-02-16

【中文标题】多少列是太多列？ [关闭]

【英文标题】：How many columns is too many columns? [closed]

【发布时间】：2011-03-12 04:47:26

【问题描述】：

我注意到这里的很多人都引用了一张表中有 20 多列（我见过多达 55 列）的表。现在我不假装自己是数据库设计专家，但我一直听说这是一种可怕的做法。当我看到这一点时，我通常建议拆分为具有一对一关系的两个表：一个包含最常用的数据，另一个包含最不常用的数据。虽然同时，可能存在性能问题（更少的 JOIN 等）。所以我的问题是：

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

哪一个对性能的影响更大：很多列有很多 NULL，还是更少的列有很多 JOIN？

【问题讨论】：

似乎很明显，这完全取决于数据库的要求以及对它执行的每个相应操作的繁重程度。感谢您的回答。

我认为该过程是将数据库和表设计为第 3 或第 4 范式，然后为性能进行非规范化。流程不是驱动列数，而不是开发人员的感受吗？

50 列不是很多，但在我看来，当表格有太多超过 300、400 的列时，您必须查看整个应用程序以及谁在设计它，看看是否有模式的重复。你可能会找到一些。在生产应用程序中拆分大表可能很困难，因此最好从良好的基础开始。

【参考方案1】：

表的设计取决于它需要存储的实体。如果所有数据都属于一起，那么 50 列（甚至 100 列）可能是正确的做法。

只要表是normalized，除了数据库功能和需要优化之外，没有关于大小的经验法则。

【参考方案2】：

我同意奥德的观点。我见过有 500 列的表格，其中的所有列都在正确的位置。只要考虑一下人们可能希望存储的关于日常物品的事实数量，您很快就会明白为什么。

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

【参考方案3】：

这对性能影响更大： 有很多 NULL 的列，或者 包含大量 JOIN 的列更少？

这完全取决于您存储的数据、您创建的索引等等。在不知道您存储什么的情况下，没有人可以确保您的工作比另一个更好。通常，如果您有大表，规范化规则将“强制”您将数据分隔到不同的表和用户 FKey，但我不同意它总是比一张大表执行得更好。您可以在数十个查询中以 6-7 级连接结束，这有时会导致错误，因为在较大的查询中产生错误的机会比在简单的查询中要多。

如果您发布一些您正在做的事情的要求，也许我们可以帮助您正确设计数据库。

【参考方案4】：

odbc 的字符数限制为 8000 .... 所以这是一个物理限制，如果超出这个限制，事情就会变得非常令人沮丧。

我在一张有 138 列的表上工作。它写得很糟糕，本来可以标准化的。虽然这个数据库似乎是有人想知道为什么在数据库设计中有约定并决定一次性测试它们的创建。

当您进入数据仓库和报告服务器时，拥有非常宽的扁平表是相当普遍的。它们的速度要快得多，这意味着您不必为了性能而将数据库全部存储在 ram 中。

【参考方案5】：

多少列算多列？

当您觉得不再有意义或添加另一列是正确的时候。

通常取决于应用程序。

【参考方案6】：

根据我的经验，最好减少连接，因为这些连接往往发生得太频繁，尤其是在大型数据库中。只要您的数据库表设计为存储单个实体（学生、教师等），这应该没问题。这样这将在稍后的代码中表示为一个对象。因此，如果您将实体拆分为多个表，您将不得不使用多个连接以便稍后填充您的对象。此外，如果您使用 ORM 生成数据访问层（例如 .Net 中的 Linq），将为每个表生成单独的类（当然它们之间存在关系，但仍然存在），这将更难使用。

另一件事是，您可以指定要在查询中返回哪些列，这将减少传递给您的应用程序的数据，但如果您甚至需要另一个表中的单个列，则必须进行连接。而且在大多数情况下，由于您有这么多列，那么在数据库中存储大量数据的可能性就很高。所以这个连接会比 NULL 造成更多的伤害。

我参与的每个项目都不同，因此您应该为每个故事找到平衡点。

【讨论】：

非常正确。显然，连接和多选查询很慢，因此应尽可能考虑非规范化，而不会像您建议的那样破坏一致性。

【参考方案7】：

这也很大程度上取决于您的桌子的用例。如果您想优化它以供阅读，那么将它们放在一个表中可能是个好主意。

在 NO-SQL 世界（例如 cassandra/hbase）中，对列数没有限制，实际上拥有许多列被认为是一种好习惯。这也来自它的存储方式（没有间隙）。值得研究。

【参考方案8】：

最好使用单个表，这样可以避免在查询时使用连接，这取决于列是同一实体还是不同实体。

例如，假设您正在为工作流程进行数据库设计，其中一些字段将由初级员工编辑，而一些字段将由高级员工编辑。在这种情况下，最好将所有列放在一个表中。

【讨论】：

-1：为什么更好？ 以什么方式更好？

【参考方案9】：

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

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