谁还没个对着手机相册发呆的毛病呢？非得把照片塞进“2023年旅游”“工作截图”的文件夹里。微信翻到半年前的聊天记录，第一反应居然是“这能不能备份到网盘”。折腾完了，你仔细品品，骨子里跟徐人凤那本《关系数据库基础》里讲的“关系规范化”简直是一个模子刻出来的。书里掰扯第一范式到第三范式，核心就一句：把数据表里的冗余依赖砍干净，用死板结构换绝对一致。可我真把这套逻辑往自个儿生活里套，越琢磨越觉得哪儿不对劲儿。规范化本来就是把手术刀，图的是精准。你非拿它当电锯使，能不崩口子吗？真要养好一个系统，关键得看你手稳不稳。知道哪一刀下去，必须收手。
书里推演得确实硬。作者把话挑明了：表里要是留着传递依赖或者部分依赖，麻烦事立马就冒头。插入异常、删除异常、更新异常，全跟着来。我拿个最土的比方说，非要把“学生姓名”和“课程成绩”硬塞进一张表里。改个名，你得动十几行字；退学一个学生，连带着把一门课的记录给抹了。规范化的解法？拆分表，拉外键，把乱成一团的线头理顺。这操作熟不熟悉？像极了咱们平时搞知识管理，或者捋人际关系的执念。把重叠的信息往外抽，模糊的关联直接斩断。每个概念，就得给它安个唯一的家。真要这么干，确实能避免很多“更新异常”。省得因为随口一句话引发连锁误解，也免得跟人闹掰了，扯出一地碎玻璃渣子。不过话说回来，这事儿未必适合所有人。有时候太较真，反而把日子过僵了。
真以为生活能按OLTP环境跑？现实哪有那么单一？规矩是死的。人是活的。数据库搞规范化，默认前提是你得跑事务处理，一致性必须排在第一位。但现实世界哪是什么单一的OLTP环境啊？真要把“规范化”往死里卷，生活立马就沉得拽不动了。我见过太多朋友，笔记做得跟瑞士钟表似的。MECE原则拆得明明白白，标签体系层层嵌套。到头来想查点东西，鼠标在七八个文件夹之间来回跳转，眼睛都快出残影了。数据库里这叫“多表连接查询”，狂吃计算资源；落到人身上，就是实打实的“认知过载”。你死磕结构的完美，直接把调取信息的速度给打折了。反过来想想呢？那些看似冗余的重复话头，饭局上的客套，甚至工作中一些“不合规”但能直接推进项目的土办法。全是系统自带的缓存。没这层缓冲，每次响应都得重新建连。效率能不断崖式下跌吗？我觉得这事儿大概就是这么个意思。
说到这儿，作者其实悄悄画了条线。关系规范化能跑通，得看你付不付得起结构维护的成本，以及错误代价是不是极高。可要是碰上快速迭代、容错率低的场景，过度规范化就是往自己脖子上套枷锁。数据库设计里早就有“反规范化”这招了。为了读性能故意保留冗余，拿空间换时间。过日子更是一样。亲密关系里如果事事都要“规范化”，斤斤计较谁付出的多、谁该承担哪部分责任。感情早就在一次次“数据校验”中耗尽了。咱们需要的本来就不是零冗余的真空。而是留有摩擦力的缓冲带。可能有人会觉得我太绝对，但在我看来，生活里的“脏数据”有时候反而是润滑剂。太干净了，反而容易打滑。
换个别的角度看。规范化教咱们的，难道就是怎么消灭混乱？恐怕不是。而是怎么识别混乱的类型。有些冗余，是结构本身有缺陷，得拆；有些冗余，是刻意留的冗余设计，得留着。徐人凤的书写的是冷冰冰的表结构，但底层逻辑和人的成长一样。秩序感很重要。但未必得把它供成神。别让它变成囚笼就行。真正成熟的选择，是知道什么时候该死磕第三范式，什么时候该允许数据横着放。甚至偶尔让它“脏”一点也无所谓。
所以啊。下次手痒想给生活做“大扫除”的时候，先掐自己一下。我是在消除真正的异常，还是在消灭必要的冗余？关系的秩序，从来不在绝对的干净里。全在留有余地的弹性中。这事儿大概也就这么个理儿。书还得翻，日子还得过。留点缝隙，反而喘气更顺当。