以下这7个问答皆适用于事务型数据库设计:
1、问:是否为每个表设置一些备用字段?
答:没办法,我总是设计不出“完美”的数据表,给每个表加几个备用字段(我一般用字符串型,随你)可以应付“不时之需”,尤其是需要长期维护的、业务可能有临时性变动的系统。
2、问:尽量不要在一个表中存入其关联表的字段?
答:建议不存!这样做确实可以提高查询效率,但在一个有很多表,并且关联表多的情况下,很难保持数据的一致性!数据库结构也比较糟糕。而且不存,也不会使效率十分低下。
3、问:是否使用联合主键?
答:个人倾向于少采用联合主键。因为这样会降低索引的效率,联合主键一般都要用到至少一个业务字段,往往是字符串型的,而且理论上多字段的索引比单字段的索引要慢些。看上去似乎也不那么清爽。 在实际的事务型
数据库设计中,我尽量避免使用联合主键,有些时候“不得不”使用联合主键。
4、问:不能去直接修改数据库?
答:个人认为这点很重要,当需要修改时,应该先去修改模型,然后同步物理数据库,尤其是团队
开发,否则要多做更多的事情来搞定,也可能会引入更多的错误。
5、问:为每个表增加一个state字段?
答:我习惯在设计时给每个表设一个state字段,取值0或1,默认值为1,具体业务意义或操作上的意义可以自定义。可以作为一个状态控制字段,如查询、更新、删除条件,单据是否有效,甚至仅仅是控制一条数据是否“有效”。在数据迁移时也可能会发挥作用。
6、问:不要使用多对多关系?
答:个人倾向于少使用多对多关系。这个问题其实不是数据库设计的问题了,在数据库设计中,多对多关系也仅仅存在于概念模型(E-R)阶段,物理模型不在有多对多关系,实际数据库中也不会有“多对多”关系。个人实际使用中,设计时基本不考虑多对多关系,但编码时总会有小组成员使用一些多对多关系。
7、问:PK采用逻辑主键还是业务主键?
答:个人倾向于“逻辑主键”,理由是这样设计出的数据库模型结构清晰、关系脉络清楚,往往更符合“第三范式”(虽然不是故意的,呵呵)。而且更容易避开“联合主键”,而且可以使用索引效率高的字段类型,比如int、long、number。“业务主键”则可以提升查询编码的简洁度和效率。
总体来说“逻辑主键”比“业务主键”执行效率低,但不会低到无法满足需求。采用“逻辑主键”比采用“业务主键”更利于数据库模型的结构、关系清晰,也更便于维护。 对于分析型数据库,如数据仓库,千万不要这样做。