MySQL 不用外键的话，如何让表起来关联呢？

[cl903254852]

Mysql刚入门，看到有人说表关联不要用外键约束。

我就有点懵逼了

1. 如果不用数据库的外键关联，那表之间应该怎么关联呢？
2. 不用外键约束，怎么保证表的数据完整性和一致性的维护？

[cl903254852]

@nekolr 你说的对。但是这样的话，ER 图就用不了了，这也是不用数据库外键关联的缺点之一，也是我觉得很可惜的点

[cl903254852]

@jay0726 为了性能，牺牲了不少好东西，比如 ER 图

[cl903254852]

@wysnylc 赞同

[cl903254852]

@zazalu 你说的弱约束一般是指用代码控制吧

[qiyuey]

17 楼说的很对，数据库往往是性能瓶颈，所以使用逻辑外键替代物理外键，并不是说外键的概念有问题，而是实际工程发展出来的解法

[Mac]

先去搞懂 join 语句的运行逻辑。利用关键字段的关联写业务逻辑就行了。

[Austaras]

@Mosy 业务量大和对性能要求高并不等同,银行等金融业里遇到的大部分性能问题都可以加钱解决

[wysnylc]

@Mosy #19 不需要效率不代表没有高性能,堆硬件和代码优化同样可以达到高性能
效率是相对的,如果银行不使用外键关联强约束性能会更好,懂了吗?

[younfor]

楼主说的大概是数据库层面的物理外键吧。还是看业务场景吧，外键本身设计是在数据库层面实现强一致性和完整性数据约束的。如果你的正确性大于性能的话，可以使用，当然也会有维护成本。不用外键的话，也可以在业务逻辑层用程序代码控制，这个数据会和业务同步修改会有耦合性。

[wysnylc]

@lolizeppelin #20 那银行不敢让你写业务...谁敢这么删数据

[passerbytiny]

@cl903254852
首先，真正的 ER 图是业务模型，它需要先转换成逻辑模型，再转换成物理模型后，才能与数据库扯上关系。
其次，即使是偷懒方式下的 ER 模型，也只需要保证正向工程（ ER 图—>数据库结构）时刻可用，不需要保证反向工程总是可用，反向工程只是用来帮助你首次设计 ER 图的时候偷懒的，不是必选项。

[dog82]

在业务层自己写代码控制，不要用 mysql 的外键约束

[leo108]

@wysnylc 所以在你眼里只有互联网行业才用得着数据库了？看不见我回复里的『看具体业务』这么几个字？

[wangxiaoaer]

想问下你们自己业务层做控制，那么关联查询后分页之类怎么做？

难道业务层两个表全部查出来，然后交叉对比？

[xaplux]

只是不用外键约束（比如 MySQL 的外键约束），又没有说不让用外键的那套逻辑，只不过这套逻辑在程序中控制了，ER 图该画的还是要画啊。该怎么表示外键的还是怎么表示就好了

[shintendo]

@wangxiaoaer 在业务层维护约束，不是在业务层 JOIN 啊……

[wysnylc]

@leo108 #33 所以我明说了外键在银行和银行之外的区别,需要严谨的就得抛弃效率拥抱外键,需要效率就抛弃严谨抛弃外键
我打的比方有问题?

[chinvo]

@wysnylc #15 你需要 ON DELETE 和 ON UPDATE

[akira]

刚入门别看这些 华丽花哨的东西，老老实实把数据库的基础知识概念学好了先。
要不要外键，什么时候要 什么时候不要 这些是生产工作的事情 还不到你接触的时候

[workspace]

users --> id name age is_del
class --> id name is_del

class_user --> id class_id user_id is_del

# 伪代码
查找用户所在 class
class_id = select class_id from class_user where user_id = ${need_query_user_id} and is_del = 0
class = select * from class where id = class_id and is_del = 0
查找 class 中的用户
user_id_list = select user_id from class_user where class_id = ${need_query_class_id} and is_del = 0
user_list = select * from users where id in (user_id_list) and is_del = 0