关于“数据”的上下属数据列表设计问题。

Question

前提

客户信息和订单信息管理；前提是 这个系统要N品牌N店面同时使用录入客户和订单信息。
有角色 店员 和 店长 和 品牌经理

大致问题（系统设计优化）

关于信息的所属冗余字段，所属人(userid)、店面、品牌，还有上下级关系数据库怎么设计更佳。

目前设计

1、客户表和订单表都有冗余字段 userid（所属人ID）、shopid（店面ID）、brandid（ID）；这么做的确在某些时候查询方便一些，如我想要某品牌的全部订单数据就不用关联查询了。

2、关于客户信息列表和订单信息列表，现在设计的是 所有用户有一个 下属字段（subid）,以1,2,3,4 逗号隔开所有下属的userid来存储。客户、订单列表为了不多做两个或更多，只做了一个，查询数据的时候 in subid （下属字段）来查，这样就是 店员进去没有下属(subid空)只看到自己的，店长进去（subid下属是他店面的）所以他看他整个店面的数据，品牌经理(subid下属是他整个品牌的)，至于其他角色 财务 下单 库房什么的 根据不同权限单独做模块来看数据

详细问题

1、由于客户 关联 订单 订单有关联N个表，什么送货记录啊，安装记录啊，审核记录啊。等等。这些所属人 所属品牌，所属店面冗余字段 这么设计到底是不是最佳的。因为如果一旦有员工离职，这个账号不能删除 是否保留 还是转移其他人名下，处理起来就麻烦死。

2、关于上下级关系，user表里 给一个下属字段序列 这么设计上下属关系是否是真的好。

盼大神指教！

Answer 1

1、多表关联就join + 外键约束，不要搞反范式设计。多表join不会慢多少。真感觉影响系统性能的时候再考虑数据库重构，不要过度设计。

2、parent_id设计很常见，并不会有什么问题。

3、加个status字段来表示是否在职，员工离职就转移数据到其他员工的id下。并且额外搞个表记录这种财产转移日志。