1、 部门、员工等编号尽可能编码手动输入。即使不能直接自动生成编码字符串,也要根据客户的需求设计编码生成规则。避免编码重复。
2、 与客户沟通需求时,需要考虑全面,将客户模糊需求的潜在风险告知,供客户确认。
3、 做需求设计时,要针对主要流程及模块间关联进行。对于系统可配置的数据项,如哪些请假类型只能申请一次等,没有必要在做需求时弄清楚。提供几个类型实现功能,待客户试用时要求提供列表进行预配置或者由客户自主配置列表皆可。
4、 各种针对数据库的操作,尤其是数据变化或消失的操作,需要有对应的日志表。不仅可以作为记录查询,也可能在一些功能中会使用到日志表中的数据。
5、 要了解各功能客户的操作频率、重视度,针对操作频率和重视度高的模块功能优先实现及完善。
6、 系统设计:
a) 系统整体设计时,要清楚该系统需要为其他相关系统预留的接口、系统各模块间的关联。
b) 模块设计时,考虑与其他模块间的关联和数据接口。
c) 模块设计及数据库设计时,需要根据客户需求分析各功能的共性,能合并的进行合并。对于客户特别重视和日常操作频率明显高的功能可以独立设计。
d) 数据库冗余字段的必要性。
以员工、部门、岗位为例,在流程性表中,如审批表,审批人同时要存入部门id,用于还原真实场景(谁审批的,处理的时候该审批人在哪个部门,处于什么职务)
用户操作频率高、数据量大的表,进行数据冗余。比如数据量特别大的表,最好在存部门id的时候同时存入部门名称,缓解在联合查询时的数据库压力。是否设计冗余字段要依据表的功能来判断。若该表只是针对员工的某项记录,而不会涉及部门的数据分析便可不加冗余字段。
e) 做设计时,首先关注客户特殊需求、数据接口、流程、共性合并等,不要过于在意细节。