讨论下，严格按关系表规范设计，订单表只保存客户表的客户id的弊端！

Question

好，你说的好轻巧呀，这样的话，订单表就不能与客户信息表关联了，就要与“客户信息变更表”关联了，而且关联字段也不是简单的“客户id”了，而是客户id+月份，此时需要另外创建一个客户信息变化表，也要一月一个，即每月保存一份客户的当月信息。
这会使表的关系复杂很多，而且每次 select 时，订单表都要 按照月份与客户id去left join“客户信息变更表”，代码看着就麻烦。其实在订单表中，多加几个字段就全好了，何必再关联更多的表呢？想不明白。

Answer 1

如果这样设计的话，那么当客户的信息变化时，订单表的历史状态将无法看到。因为客户的基本信息也是会变化的，比如email,地址（搬家了），这时就需要修改客户信息表，比如将地址修改了，这就会造成问题，因为订单表关联的客户信息表，所以再次查看以前的订单时，看到的地址是现在修改后的地址，可是这个订单当时并不是这个地址呀，我们现在将无法再查到这个订单的历史状态了，因为曾经的“地址”信息已经丢失了。---这可是个严重的问题吧。所以我认为，要采取折中的办法，即在订单表中，不能只存放客户的id信息，还有存放一些便于以后追溯的信息（比如地址，比如email），即无论何时查询历史订单，有些必须信息要永远存在的（也就是说要“物理存在的”），不能依赖于关联操作才能得到。
====
这种考虑特殊情况的思维方式会把问题复杂化。本质上，这依然符合关系理论3NF的要求：如果一个Email依赖于客户ID（即客户的当前Email），则这个字段应该放在客户表，放在订单表则违反3NF；
如果一个Email依赖于订单ID（即订单的关联Email），则这个字段应该放在订单表。
这个Email字段依赖于哪个ID，取决于系统需求。LZ的情况，需要客户表有一个Email字段表示客户当前最新Email，订单表有一个CustomerEmail字段表示订单关联的客户Email。当然，客户信息变更历史表也需要有，主要是为了记录历史信息；把历史表与订单表关联，会增加问题复杂度。

Answer 2

是的。否则，就像5楼所说，你的订单关联的就不是客户ID，而是客户ID+时间（或客户历史LogID）。