哪个更有效:多个MySQL表或一个大表?

我在我的MySQL数据库中存储各种用户详细信息。 最初它被设置在各种表中,意味着数据与UserIds链接,并通过有时复杂的调用来输出,以根据需要显示和处理数据。 build立一个新的系统,将所有这些表合并成一个相关内容的大表格几乎是合理的。

  • 这会是一个帮助或阻碍?
  • 调用,更新或search/操作时的速度考虑?

下面是我的一些表结构的一个例子:

  • 用户 – UserId,用户名,电子邮件,encryption密码,注册date,IP
  • user_details – cookie数据,名称,地址,联系方式,从属关系,人口统计数据
  • user_activity – 贡献,上线,上次查看
  • user_settings – configuration文件显示设置
  • user_interests – 广告可定位的variables
  • user_levels – 访问权限
  • user_stats – 匹配,logging

编辑:到目前为止我已经提出了所有答案,他们都有元素,基本上回答我的问题。

大多数表格都有1:1的关系,这是造成非规范化的主要原因。

如果表格跨越100列以上,那么这些单元格的大部分可能保持空着,是否会出现问题?

多个表有助于以下方式/案例:

(a)如果不同的人将要开发涉及不同表格的应用程序,则将它们分开是有意义的。

(b)如果你想在不同的部门收集不同的资料给不同的人,可能会更方便。 (当然,你可以看看定义的意见,并给予适当的授权)。

(c)为了将数据移动到不同的地方,特别是在开发过程中,使用表格可能会导致文件较小。

(d)当你开发一个实体的特定数据收集应用程序时,较小的脚印可能会给人以舒适的感觉。

(e)这是一种可能性:你认为单一价值数据在将来可能变成真正的多重价值。 例如信用额度是目前单一的价值领域。 但明天,您可能会决定将其值更改为(从date到date,信用值)。 拆分performance在可能来得方便。

我的投票将是多个表 – 数据适当分割。

祝你好运。

组合这些表称为反规范化。

它可能(也可能不会)帮助做一些查询(这使得大量的JOIN s)以更快的速度运行,而创build一个维护地狱的代价。

MySQL只能使用JOIN方法,即NESTED LOOPS

这意味着对于驱动表中的每条logging, MySQL在循环中查找驱动表中的匹配logging。

查找logging是相当昂贵的操作,可能需要数十倍的纯logging扫描。

将所有logging移动到一个表中将帮助您摆脱此操作,但是表本身变大,表扫描需要更长的时间。

如果其他表中有大量logging,则增加表扫描可能会超出正在顺序扫描的logging的好处。

维护地狱,另一方面,是有保证的。

他们都是1:1的关系吗? 我的意思是,如果用户可能属于不同的用户级别,或者如果用户兴趣在用户兴趣表中被表示为多个logging,那么合并这些表就不会立即出现问题。

关于规范化的以前的回答,必须说数据库规范化规则已经完全忽视了性能,只是看什么是一个整洁的数据库devise。 这通常是你想达到的目的,但是有些时候,为了追求绩效而主动去规范化是有意义的。

总而言之,我想说的是,问题归结为表格中有多less个字段,以及它们被访问的频率。 如果用户活动通常不是很有趣,那么出于性能维护的原因,将它放在相同的logging上可能是一件令人讨厌的事情。 如果某些数据(如设置)经常访问,但是只包含太多字段,则合并表格可能也不方便。 如果只对性能增益感兴趣,则可以考虑其他方法,例如保持独立的设置,但将它们保存在自己的会话variables中,这样就不必经常为它们查询数据库。

所有这些表都有1-to-1关系吗? 例如,每个用户行在user_statsuser_levels只有一个对应的行吗? 如果是这样,将它们合并成一个表格可能是有意义的。 如果这种关系不是 1 to 1 ,那么把它们合并(非规范化)可能是没有意义的。

把它们放在单独的表中,而不是一张表,对性能的影响可能不大,除非你有成千上万或数百万的用户logging。 你将得到的唯一真正的好处是通过组合它们来简化你的查询。

ETA:

如果你担心的是有太多的列 ,那么考虑一下你通常使用的东西,并把它们结合起来 ,剩下的放在一个单独的表格中(如果需要,还可以使用几个单独的表格)。

如果你看看你使用这些数据的方式,我的猜测是你会发现80%的查询使用了20%的数据,其余80%的数据只是偶尔使用。 将经常使用的20%组合到一张表中,并将不经常使用的80%留在单独的表中,这样可能会有很好的折衷。

创build一个巨大的表违背了关系数据库的原则。 我不会把他们全部合并成一张桌子。 你将得到重复数据的多个实例。 例如,如果你的用户有三个兴趣点,你将有三行,用相同的用户数据来存储三个不同的兴趣。 肯定去多个“规范化”的表格方法。 请参阅此 Wiki页面以进行数据库规范化。

编辑:我已经更新了我的答案,因为您已经更新了您的问题…我现在更加认同我的最初答案,因为…

这些细胞的大部分很可能保持空白

例如,如果用户没有任何兴趣,如果你正常化,那么你简单的不会在该用户的兴趣表中有一行。 如果你在一个巨大的表中有所有的东西,那么你将有列(只是很多),只包含NULL的。

我曾经在一个有大量表格的电话公司工作,得到的数据可能需要很多连接。 当从这些表中读取performance是关键的时候,那么创build的程序可能会产生一个不需要连接,计算等报表可能指向的平坦表(即非规格化表)。 这些地方随后与SQL服务器代理一起使用,以一定的时间间隔运行作业(即每周查看某些统计信息将每周运行一次,等等)。

为什么不使用相同的方法Wordpress通过用户表具有每个人都拥有的基本用户信息,然后添加一个“user_meta”表,该表基本上可以是与用户ID关联的任何键值对。 因此,如果您需要为用户查找所有元信息,则可以将其添加到您的查询中。 如果不需要login等function,您也不一定要添加额外的查询。这种方法的好处还可以让您的表向您的用户添加新function,例如存储他们的叽叽喳喳句柄或每个个人兴趣。 您也不必处理相关ID的迷宫,因为您拥有一张统治所有元数据的表格,您将其限制为只有一个关联而不是50个。

WordPress专门做了这个function,可以通过插件添加function,因此可以让您的项目更具可扩展性,如果您需要添加新function,则不需要完整的数据库检修。

我认为这是“视情况而定”之一。 有多个表更清洁,理论上可能更好。 但是,如果您必须join6-7个表来获取有关单个用户的信息,则可能会开始重新考虑这种方法。

我想说这取决于其他表格的真正含义。 user_details是否包含多于一个/用户等等。 什么样的标准化水平最适合您的需求取决于您的要求。

如果你有一个索引好的表,可能会更快。 但另一方面可能更难维护。

对我来说,它看起来像你可以跳过User_Details,因为它可能是与用户的1对1关系。 但其余的可能是每个用户很多行?