MySQL: 多个表还是多列的一个表?

所以这更像是一个设计问题。

我有一个主键(比如用户的 ID) ,并且有大量与该用户相关的信息。

我是应该根据信息将多个表分解为多个类别,还是应该只有一个包含多个列的表?

我过去使用的方法是有多个表,比如,一个表用于应用程序使用数据,一个表用于配置文件信息,一个表用于后端标记等,以保持事情看起来有条理。

最近有人告诉我,最好不要这样做,拥有一个包含大量列的表是可以的。问题是,所有这些列都有相同的主键。

我对数据库设计很新,所以哪种方法更好,优缺点是什么?

传统的做法是什么?

104113 次浏览

传统的方法是在星型模式或雪花模式中使用不同的表。然而,我认为这个策略是双重的。我相信数据应该只存在于一个地方的理论,在那里我提到的模式会很好地工作。然而,我也相信对于报告引擎和 BI 套件来说,柱状方法将是非常有益的,因为它更支持报告需求。像 infobright.org 这样的柱状方法具有巨大的性能提升和压缩,这使得使用这两种方法非常有用。许多公司开始意识到,组织中只有一个数据库架构并不能支持他们所有的需求。许多公司都实现了拥有多个数据库体系结构的概念。

任何时候信息都是一对一的(每个用户都有一个名称和密码) ,那么最好使用一个表,因为这样可以减少数据库检索结果所需的连接数。我认为有些数据库对每个表的列数有限制,但是在正常情况下我不会担心这个问题,如果需要,以后总是可以分割它。

如果数据是一对多的(每个用户有数千行的使用信息) ,那么它应该被分割成单独的表以减少重复的数据(重复的数据浪费存储空间,缓存空间,并使数据库更难维护)。

你可能会对维基百科关于 数据库规范化的文章感兴趣,因为它深入讨论了其中的原因:

数据库规范化是组织关系数据库的字段和表的过程,目的是减少冗余和依赖性。规范化通常涉及到将大型表划分为较小的(且冗余较少的)表并定义它们之间的关系。其目的是隔离数据,以便只在一个表中对字段进行添加、删除和修改,然后通过已定义的关系在数据库的其余部分进行传播。

反规范化 也是需要注意的,因为在有些情况下重复数据更好(因为它减少了数据库在读取数据时需要做的工作量)。我强烈建议在开始时使数据尽可能规范化,只有在意识到特定查询中的性能问题时才反规范化。

问问你自己这些问题,如果你把所有的东西放在一个表中,你会为那个用户有多个行吗?如果需要更新用户,是否需要保留审计跟踪?用户是否可以拥有一个以上的数据元素实例?(比如电话号码)你会不会遇到这样的情况,你可能想在以后添加一个元素或者一组元素? 如果您回答是,那么很可能您希望拥有具有外键关系的子表。

父表/子表的优点是数据完整性,通过索引的性能(是的,你也可以在平面表上做到) ,以及如果你以后需要添加一个字段,特别是如果它将是一个必需的字段,IMO 更容易维护。

缺点是设计比较困难,查询比较复杂

但是,有很多情况下,一个大的平台将是合适的,所以你必须看看你的情况来决定。

一张大桌子通常是个糟糕的选择。相关的表格是关系数据库设计用来工作的。如果正确地编制索引并知道如何编写性能查询,那么它们将执行得很好。

当表获得太多列时,可能会遇到数据库存储信息的页面实际大小的问题。要么是记录对于页面来说太大了,在这种情况下,你可能无法创建或更新一个让用户不满的特定记录,或者(至少在 SQL Server 中)你可能被允许为特定数据类型溢出一些记录(如果你这样做,你需要查看一组规则) ,但是如果许多记录会溢出页面大小,你可能会造成巨大的性能问题。现在,MYSQL 如何处理页面,以及当潜在的页面大小变得过大时是否有问题,这些都是您必须在该数据库的文档中查找的内容。

我已经完成了一些数据库设计。对我来说,这取决于系统在数据库管理方面的难度; 是的,只在一个地方有唯一的数据是真的,但是在有大量记录的过度规范化的数据库中查询是非常困难的。只要把这两个模式结合起来,使用一个巨大的表格,如果你觉得你将有一个大量的记录,很难维护,就像 facebook,gmail 等,并使用不同的表格为一套简单的系统记录... 好吧,这只是我的意见。.希望能帮上忙。.照做就是了。.你可以的... :)

我有一个很好的例子。过度标准化的数据库与下面的关系集:

people -> rel_p2staff -> staff

还有

people -> rel_p2prosp -> prospects

当人们有名字和人员的详细信息时,员工只有员工记录的详细信息,潜在客户只有潜在客户的详细信息,而 rel 表是与外键的关系表,这些外键来自与员工和潜在客户联系的人。

这种设计对整个数据库进行。

现在,要查询这组关系,每次都需要进行多表联接,有时需要8个以上的表联接。到今年年中为止,它一直运行良好,但现在我们已经超过了40000人的记录,它开始变得非常缓慢。

索引和所有低悬挂成果在去年已经用完,所有查询都优化到了完美的程度。这是特定的规范化设计和管理的道路的尽头,现在批准了一个重建的整个应用程序,依赖于它以及重组的数据库,在6个月的任期。哎哟。

解决方案将是 people -> staffpeople -> prospect有一个直接关系

我认为有一个单一的表格更有效,但是你应该确保表格的组织方式能够显示同一行的关系、趋势以及变量之间的差异。 例如,如果表格显示的是学生的年龄和成绩,你应该按照感谢得分最高的学生和得分最低的学生区别很大的方式来安排表格,而且学生的年龄差异是相等的。

遇到这种情况,作为一个过去经常使用 mySQL 的人,最近又转移到了 Postgres,最大的优势之一就是你可以在 Postgres 的一个字段中添加 JSON 对象。

所以,如果你处于这种情况,你不必在一个有很多列的大表和分割它之间做出选择,但是你可以将列合并到 JSON 对象中来减少它,例如,地址不是5列,它可以只是一列。您也可以查询该对象。