mysql - 有多少列太多了？

Question

mysql - 有多少列太多了？

Bra*_*rad 105 mysql sql

我正在设置一个可能超过70列的表.我现在正在考虑将其拆分,因为每次访问表时都不需要列中的某些数据.然后,如果我这样做,我将不得不使用连接.

在什么时候,如果有的话,它被认为是太多列？

Answer 1

Chs*_*y76 133

一旦超过数据库支持的最大限制,就会被认为太多了.

您不需要每个查询都返回每个列的事实是完全正常的; 这就是SELECT语句允许您明确命名所需列的原因.

作为一般规则,您的表结构应该反映您的域模型; 如果你确实拥有属于同一实体的70(100,你有什么)属性,那么没有理由将它们分成多个表.

@KM - 这就是为什么我说"在域模型上属于同一实体的属性".表中的大量列不会使其非规范化; 这就是列表示重要的内容.此外,虽然规范化绝对是一件好事,但它并不能解决所有生活中的问题.诀窍问题 - 你认为SO问题/答案旁边的投票数是每次计算为"从投票中选择计数(*)"还是你认为它可能是非规范化的？这会让SO数据库变坏,而Jeff Atwood会疯狂吗？ (28认同)
"numberOfTeethPulled"应该是Person记录的一部分吗？不,它可能根本不应该存储 - 如果您的域模型需要这样的详细程度,您将从"ToothExtractionRecord"获取该信息.但这就是你的(并且,我敢说,而且是设计的)例子 - 它与我的观点毫无关系:表中的大量列并不意味着表被非规范化.以房地产合同/采购订单/其他财务文件为例,仅举几例.它们可以进一步分成多个表吗？是.有什么理由这样做吗？并不是的. (17认同)
如果你有一个表"人"你通常有像"name","sex","dateOfBirth"等列,如果你开始添加像"isSoccerPlayer"和"numberOfTeethPulled"这样的列只是因为数据库列的最大限制没有已经到达,你不仅疯了,而且创建了一个糟糕的数据库,实际上你正在努力工作.你可能会认为你让它变得更容易,但你真的不是.你正在与数据库如何工作,看看正常化 (4认同)
+1，太搞笑了。如果您正在创建另一个表，并且它将是 1:1 的关系，您可能应该将它包含在主表中。它不会节省空间，如果您不请求数据而不是它根本不在表中，它的性能不会好得多。我现在想到的唯一合法原因是那里是否有敏感信息，例如 SSN、信用卡信息等... (2认同)
如果我有一个表有 15 列，另一张表有 300 列，则两个表的主键是相同的。在两个表中选择一列，性能会明显不同吗？ (2认同)

Answer 2

jon*_*ohn 26

将表拆分为具有较少列的几个表有一些好处,这也称为垂直分区.以下是一些:

如果您有多行的表,修改索引可能需要很长时间,因为MySQL需要重建表中的所有索引.将索引拆分为多个表可以使速度更快.
根据您的查询和列类型,MySQL可能会将临时表(用于更复杂的选择查询)写入磁盘.这很糟糕,因为磁盘i/o可能是一个很大的瓶颈.如果查询中包含二进制数据(文本或blob),则会发生这种情况.
更宽的表可能导致查询性能降低.

不要过早地优化,但在某些情况下,您可以从较窄的表中获得改进.

如果只修改了一个索引,为什么MySQL需要重建表中的所有索引？ (4认同)

Answer 3

Joh*_*nFx 13

违反规范化规则时太多了.如果要规范化数据库,很难获得那么多列.设计数据库以模拟问题,而不是围绕任何关于针对特定数据库平台进行优化的人为规则或想法.

将以下规则应用于宽表,并且单个表中的列可能会少得多.

没有重复元素或元素组
对连锁键没有部分依赖关系
不依赖于非键属性

这是一个帮助您的链接.

如果你正在规范你的数据库,很难获得那么多列.没有看起来那么难. (16认同)
绝对不是那么难.人们似乎并不真正了解这些部分的正常形式.您可以拥有10000列并且仍然可以标准化(即使是最高的正常形式). (5认同)
当你开始谈论汽车时,你失去了我.不知道相关性是什么. (3认同)
@foljs而这正是被接受的非规范化实践所带来的.如果你在一个十字路口并且一辆汽车即将驶入你,那么等待灯变绿是愚蠢的.你必须摆脱困境.虽然通过红灯在技术上可能不合法,但你应该做的事情显然应该是因为情况=非规范化 (2认同)
但是,如何在这种情况下使用单个数据表进行复杂查询,你不能,你必须严重依赖编程语言和其他各种东西来完成这项工作!所以,我不妨回过头来看一个包含170列的表,因为在我看来,单独的表需要"JOIN"查询和额外的复杂编程似乎浪费时间.我想我是KISS原则的忠实粉丝. (2认同)

归档时间：	16 年，4 月前
查看次数：	52539 次
最近记录：	6 年，6 月前