比如有个商品表
这个时候新增一个功能叫针对某些商品进行限时优惠 那么这个时候有一张限时优惠商品表 goods_id挂钩商品表主键
又有一个功能是赠送商品 这个时候又有一张赠送商品表 goods_id挂钩商品表主键
那如果我删了商品表的某些数据 那么其他与商品有关的表都要删除
问题是如果业务越来越大 这部分会牵连的越来越多 相当于操作了商品表就需要操作与商品有关的表 请问有没更好的方法了 设计思路 不用外键关联
比如统计 可能也找不到这个商品了
比如有个商品表
这个时候新增一个功能叫针对某些商品进行限时优惠 那么这个时候有一张限时优惠商品表 goods_id挂钩商品表主键
又有一个功能是赠送商品 这个时候又有一张赠送商品表 goods_id挂钩商品表主键
那如果我删了商品表的某些数据 那么其他与商品有关的表都要删除
问题是如果业务越来越大 这部分会牵连的越来越多 相当于操作了商品表就需要操作与商品有关的表 请问有没更好的方法了 设计思路 不用外键关联
比如统计 可能也找不到这个商品了
通行的做法有两个,一是不做物理删除,只做标记删除,即增加一个表示已删除的字段。
二是手动维护关联关系,不加外键的情况下,即便有未被关联删除的其他记录也没有太大关系。
实际系统中数据量很大时,外键关联也是会很少用的。
建表的时候设置级联删除啊:
CREATE TABLE 优惠商品表(
-> id INT PRIMARY KEY auto_increment,
-> goods_id TINYINT,
-> FOREIGN KEY (goods_id) REFERENCES 商品表(goods_id) ON DELETE CASCADE
-> );
这样删除商品表里的数据时,优惠商品表里的数据就会被级联删除,不需要你自己管理。
15 回答8.4k 阅读
8 回答6.2k 阅读
5 回答3.2k 阅读✓ 已解决
3 回答3.6k 阅读✓ 已解决
1 回答4k 阅读✓ 已解决
3 回答1.8k 阅读✓ 已解决
3 回答6k 阅读
不推荐使用数据库外键
除了上面说的,数据不能真删,还可以考虑一点,实际上不论是用真删还是假删,你都可以在其他关联表查询的时候把删除的数据过滤出去,也不会有影响,因为从逻辑上这个所对应的已经是不存在的了,如果你真的要考虑删除其他表的关联,可以考虑使用下面的方式。
对于每个新增的功能点,可以在监听商品表对应模型的的 更新/删除 事件,当事件发生后再做相应的事情,如果需求严格的情况下,别忘了考虑事务。