数据结构设计和说明
针对客户表样需求，设计三张物理表，分别是交接单表、业务-发展人员表、业务数据明细表；交接单表和业务-发展人员表为一对多关系，业务-发展人员表和业务明细表为一对多关系。数据结构关系图如下：
在数据结构设计时要注意：
1. 基于关系数据库的实体-关系（E-R）模型，避免出现数据冗余
例如：如果将业务数据明细与业务-发展人员合为一个表，设计图如下，则会出现填写交接单添加多个发展人员的业务数据明细时，会出现红色标识的字段FZRYID会在同一个交接单的多条业务数据明细记录中重复出现多次，并且在修改发展人员时，需要同时修改同一个交接单的多条业务数据明细记录的FZRYID值。
针对具体需求时，往往针对不同的数据结构均能找到解决方法，但需求是不断发展的，实体-关系模型反映了数据的本质结构，因此遵从实体-关系模型是最合理的方式，可以避免出现新需求时原有结构需要大幅度改动的情况。
2. 明确表间关系
例如：在本数据结构设计中，要明确表中的主外键关系，及表间对应关系。
交接单表主键为交接单号JJDID、业务-发展人员表主键为YWFZRYID、业务数据明细表主键为YWMXID。
交接单表和业务-发展人员表为一对多关系，在业务-发展人员表中通过外键JJDID关联。
业务-发展人员表和业务明细表为一对多关系，在业务明细表中通过外键YWFZRYID关联。
3. 合理使用关联的码表
例如：交接单表和业务发展人员表中分别有业务人员ID和发展人员ID，均与系统用户表t_user表关联。这两张表的字段中存储的是ID。查询码表得到人员姓名。
业务明细数据表中的业务类型一般情况下应关联对应业务类型码表（存储业务类型ID和业务类型名称），但如果业务类型固定、明确，也可以简化，如本例设计。
4. 关键字段（如用于关联的，或者基于值比较的）应建立索引
例如：交接单号、交接单日期、业务人员ID、状态等均应建立索引；备注字段因为往往只会被读取，即使在查询时也是以“包含”的方式使用（这时索引不起作用），因此不应建立索引。受理量则视查询需要而定，如果经常基于受理量的范围进行检索才有必要建立索引。
5. 如严格按照实体-关联模型，可能会造成查询统计时关联过于复杂。因此可以将部分字段重复放入相关的表中。
例如：交接单号也被放入了业务数据明细表，这样可以直接关联交接单表进行查询，提高了效率。
采取这种方式，一定要保证更新的一致性。