MySQL加入滥用？它有多糟糕？

Question

我一直在阅读关于每个SELECT上使用许多JOIN语句的关系数据库.但是,我一直想知道滥用这种方法从长远来看是否存在任何性能问题.

例如,假设我们有一张users桌子.我通常会添加"最常用"的数据,而不是做任何额外的JOIN.例如,当我说"最常用"数据时,将是用户名,显示图片和位置.

在网站上显示任何用户交互时总是需要这些数据,例如:在每个comments表JOIN上articles.不要在users&users_profilestables 上进行JOIN 以获取'location'和'display',而只需使用users表中的信息.

这是我的方法,但我知道有很多优秀且经验丰富的程序员可以就此事给我一些建议.

我的问题是:

我应该尝试保守JOIN吗？或者我应该更多地使用它们？为什么？

从长远来看,使用JOIN有很多性能问题吗？

注意:我必须澄清一点,我根本不想避免JOINS.我只在需要时使用它们.在这个例子中将是评论/文章作者,仅显示在用户个人资料页面上的额外个人资料信息......等等.

Answer 1

我对数据建模的建议是:

• 一般来说,您应该支持超过1:1连接的可选(可空)列.仍然存在1:1有意义的情况,通常围绕子类型.对于可空栏目,人们往往比他们奇怪的加入时更加娇气;
• 不要让模型过于间接,除非真的(下面更多关于这个)合理;
• 支持加入聚合.这可能会有所不同,因此需要进行测试.有关此示例,请参阅Oracle vs MySQL vs SQL Server:Aggregation vs Joins ;
• 联接优于N + 1选择.例如,N + 1选择是从数据库表中选择订单,然后发出单独的查询以获取该订单的所有订单项;
• 当你进行大规模选择时,连接的可扩展性通常只是一个问题.如果你选择一行,然后把它加入到一些东西很少这是一个问题(但有时它是);
• 除非你正在处理一个简单的小表,否则应始终将外键编入索引;

更多关于AppDevelopers的数据库开发错误.

现在关于模型的直接性,让我举个例子.假设您正在设计一个用于身份验证和授权的系统.过度设计的解决方案可能如下所示:

• 别名(id,username,user_id);
• 用户身份, ...);
• 电子邮件(id,user_id,电子邮件地址);
• 登录(id,user_id,...)
• 登录角色(id,login_id,role_id);
• 角色(身份证,姓名);
• 角色权限(id,role_id,privilege_id);
• 特权(身份证,姓名).

因此,您需要6个连接才能从输入的用户名获得实际权限.当然可能有一个实际的要求,但是这种系统通常被放入,因为一些开发人员认为他们可能有一天会需要它,即使每个用户只有一个别名,用户登录是1 :1等等.一个更简单的解决方案是:

• 用户(ID,用户名,电子邮件地址,用户类型)

而且,就是这样.也许如果你需要一个复杂的角色系统,但你也很可能不这样做,如果你这样做很容易插入(用户类型成为用户类型或角色表中的外键),或者通常很容易映射老到新.

这是关于复杂性的事情:它很容易添加并且难以删除.通常它是针对意外复杂性的持续守夜,这是非常糟糕的,没有去,并通过增加不必要的复杂性使其变得更糟.

Answer 2

一些聪明人曾经说过:

归一化直到它疼,非规范化直到它起作用!

这一切都取决于连接的类型和连接条件,但它们没有任何问题.连接ON table1.PK = table2.FK非常有效.