判断实体关系要按现实世界的可能性预判，不能只看当前业务

设计实体之间是一对多还是多对多，标准不是”当前业务需求是什么样”，而是”现实世界中这种关系有没有可能发生”。案例中账号和门店当前业务是一对多（一个门店一个账号管），但现实中”一个门店雇用多名采购员”完全合理，所以底层就该设计成多对多，哪怕暂时应用层只用到其中一部分；如果按当前需求设计成一对多，未来业务变化时，从数据库结构到几乎所有相关代码都要推倒重写。发散：这条经验把”过度设计”和”合理预留扩展性”划开了一条清晰的线——判断标准不是”我觉得以后可能用得上”，而是”这种情况在现实世界里逻辑上站得住脚吗”，站得住脚的可能性就该在数据层留出空间，站不住脚的（比如门店和订单不可能多对多）就不必为了”看起来更灵活”而画蛇添足。