同事提出来的数据设计，咨询下大家

[yannxia]

为了脱敏，这里用一个更通用的 CASE 来说明

我们有一个 用户表 和 产品目录表， 他们之间是 M:N 的关系，我认为这个表就 2 ~ 3 个字段，USER_ID 和 CATEGROY_ID 的外键，最多加上一个 CREATE_Time 但是我的同事认为一定加一个 DELETE_TIME，我们要知道他们什么时候解除关系的，并且可以通过这个查询历史（说是运营会分析[我认为是捏造的]）。

我认为这个设计不仅没有必要而且很扯淡，

1. 我们对于用户和产品本身都没有存历史记录，这里记得关系的历史记录更是没啥卵用，糟糕的可能是产品里面还会删除，这里会出现一个破坏性的 KEY
2. 关联的历史作为操作历史存在一个单独的表中，并且对于 OLTP 系统不适合做分析，找个 OLAP 的系统抓快照岂不是更好？

最终会议不欢而散，大家一般平时怎么处理这个问题。

PS：我认为包括在业务数据里加一个 Deleted 字段都是偷懒的行为，增加一个 Deleted_User 的表，将删除的数据移动一下可能会更合理点。

• should-i-delete-or-disable-a-row-in-a-relational-database

[yannxia]

@wysnylc 写了 6/7 年的代码，几乎没保留过历史的关联关系，血和泪的教训我为什么一次没遇见？

[wysnylc]

良言难劝该死鬼,慈悲不度自绝人