是应该在添加收费员的时候指定他管理的小区（楼盘），还是应该在添加小区（楼盘）的时候指定它的收费员？
A：在用户交互层面，两种应皆有之，两种情况在业务场景上同时存在
1.新开了楼盘，但是收费员工作不满，就要在新楼盘上指定收费员
2.新招了收费员，分几个还没人管理的新楼盘给他管理
*.收费员离职，调岗，其实还要考虑交换和解除关系

这个业务和数据库应该怎么设计？为什么？
A:在楼盘和收费员之间建立一个关系表，记录楼盘和收费员之间的关系，可以考虑的表设计是：
楼盘A 人员A
楼盘B 人员A
楼盘C 人员B
楼盘D 人员C
楼盘+人员 作为复合主键
要问为什么的话。。。不为什么，多对多大概一般就是这么设计的

都可以。而且还可以在收费的时候才临时指定。

软件交互界面设计，应该以千变万化的用户需求为出发点，不是程序员硬要说某个数据库表如何如何省事儿就篡改用户需求。

比如说原来楼盘有固定收费员，但是某一次（100户）收费其实是委托另外一个收费员去收的，这你也应该可以吧？！

指定一个人管理哪个小区，按照正规（非计算机）文档格式来分析设计。如果根本没有正规文档，用户也不想设计这样的文件，那么你开发软件的时候就不要想当然地去搞什么“指定”。程序员不能胡乱提出用户根本不想要的一堆功能界面。至于说数据库，那就跟实际文档相对应。比如说有正规的表格甚至地图来安排指定人负责哪些地域块儿，或者就是直接记录了上一次去收费分别安排谁去不同地点了（下一次默认也就使用上一次的设置），等等。

其实不是不要迂腐地满脑子只有那几个数据表。你要有尽可能100%准确的用户实际手工文档，在上面再做5倍、10倍的扩展和分析。如果满脑子只有关系数据库表，那么干产品设计就很死、没有前途。

业务上来讲，应该是先有楼盘，再有收费员，所有应该是在添加收费员的时候指定他管理的小区。

多对多的关系，一般都会用中间表来处理，即将多对多的关系分解为两个一对多的关系。

比如：1个小区内的1个楼盘可以有多个收费员，1个收费员可以管理多个楼盘。那么：

楼盘  楼盘-收费员  收费员
1         1-A         A
1         1-B         B
2         2-A         A

通过楼盘-收费员这张中间表，把楼盘和收费员这个多对多的关系，拆分成两个1对多的关系（楼盘：楼盘-收费员=1:N，收费员：楼盘-收费员=1:N）。