数据库里那些参照设置，弄懂了数据处理其实没那么难，真心推荐试试看

根据网络技术社区、个人博客中关于数据库参照完整性的通俗讨论综合整理）

你有没有遇到过这样的情况？辛辛苦苦录入了几百条客户订单，结果发现某个客户的名称写错了一个字，或者干脆把不存在的客户ID给录进去了，然后你要去改，就得把所有提到这个客户的地方一个个找出来修改，像玩“大家来找茬”一样，一不小心就漏掉一个，导致报表对不上数，头疼得很。

又或者,你想删除一个已经不再生产的产品信息，系统却弹出一个冷冰冰的错误提示，说“操作被拒绝，因为该记录已被其他表引用”，你一下子懵了，根本不知道是哪个订单或者哪个库存记录用了这个产品，只能抓瞎。

如果你被这类问题困扰过,那今天聊的“数据库里的那些参照设置”，就是你的大救星，说白了，它就是一套帮你自动维护数据之间“关系”和“对错”的规则，弄懂了它，上面那些让人抓狂的问题大半都能自动解决，数据处理真的会变得轻松很多。

那这个“参照设置”到底是个啥呢？咱们不用专业术语，就用大白话打个比方。

想象一下,你管理一个大型图书馆，图书馆里有“书架”和“借阅记录”两本大账本。

• 书架账本：记录所有藏书的信息，每本书都有一个独一无二的“图书编号”。
• 借阅记录账本：记录谁借了哪本书，以及借阅日期。

如果没有参照规则,会出什么乱子呢？

1. 管理员在“借阅记录”里可能手一滑，把一本根本不存在的“图书编号”（比如一本被销毁了的书）给登记上去，这就产生了“幽灵借阅”，这本书在书架上根本找不到，数据就乱套了。
2. 或者,图书馆决定把一本旧书下架处理，从“书架账本”里把这条记录删掉了，但这时，可能还有读者没还这本书，记录还在“借阅记录”账本里，这下好了，借阅记录里提到的书，在书架账本里查无此书，这条借阅记录就成了“孤儿记录”，毫无意义。

数据库里的“参照完整性”，就是为了防止出现这种“幽灵”和“孤儿”的，它主要干两件核心的事：

第一件事：管住你的手，不让乱填（外键约束）。 在我们的例子里，数据库可以设置一个规则：“借阅记录”账本里的“图书编号”这一栏，填写的号码必须能在“书架账本”的“图书编号”里找到。 这样一来，当你试图在借阅记录里输入一个不存在的图书编号时，数据库会立刻跳出来阻止你，就像有个严格的图书管理员在旁边盯着一样：“喂，这个编号不对，书库里没这本书，你检查一下！”这就从源头上杜绝了错误数据的产生。

第二件事：管住你的删除，不让乱删（级联操作）。 这解决的是第二个问题，当我们想从“书架账本”里删除一本书时，数据库可以根据预设的规则做出不同的反应：

• 最严格的模式（RESTRICT 或 NO ACTION）：只要这本书还有借阅记录没还（即被引用），就坚决不允许你删除，它会告诉你：“这本书还有人借着呢，不能删！”这保证了数据不会出现断裂。
• 比较智能的模式（CASCADE，也叫级联删除）：如果你确认要删除这本书，并且希望连同它的所有借阅记录一起清理掉，可以设置这个规则，当你删除书架上的这本书时，数据库会自动、瞬间地把所有相关的借阅记录也删掉，这就像这本书从来就没在图书馆存在过一样，保持了数据的整洁。（用这个要非常小心，不然可能误删重要历史记录！）
• 折中的模式（SET NULL）：删除书架上的书，但保留借阅记录，只是把借阅记录里的“图书编号”这一栏设为空，这样至少知道曾经有过借阅行为，只是书的信息不详了，这比留下一个错误编号要好一些。

你看,通过这样简单的设置，数据之间的“亲情关系”就被数据库自动维护起来了，你再也不用担心会因为手误创建出无效的连接，也不用害怕删除一条数据会留下烂摊子。

很多人在用Excel或者简单的表格软件处理复杂数据时,之所以觉得特别累，就是因为所有这些检查都得靠人眼和人脑，你得时刻提醒自己：“我删这个的时候，是不是还得去删那个？”“我改这个编号，是不是别的表里也有？”一旦数据量大了，关系复杂了，人是百分之百会出错的。

而数据库帮你把这些琐碎又关键的检查工作自动化了,你只需要提前把规则（也就是创建表的时候设置好外键关系和级联操作）告诉它，它就会成为一个不知疲倦、绝对认真的数据管家。

如果你处理的数据已经不再是简单的单张表格,而是多个相互关联的表格（比如客户表、订单表、产品表），真心推荐你花点时间了解一下你所用数据库工具的“关系”、“参照完整性”或“外键”功能，它可能一开始需要你多一点点的思考和设置，但这点投入在未来会给你带来巨大的回报——更干净的数据、更少的错误、还有你省下来的大量检查和纠错的时间，数据处理真的可以没那么难，关键是要学会让工具帮你分担那些它擅长的工作。