数据库设计

【表对应关系】

一对一

一对多

多对多的关系时，建立中间映射表；

【三大范式】

第一范式：每一个字段里描述的信息都是唯一的、不可拆分的（原子性），比如某一张表的某一个字段用XML存储很多的信息，就违背了第一范式

第二范式：描述的是属性信息，而不是一对多的对应关系。例如公司和员工的关系，一个公司会对应多个员工，需要建立一个公司表存储公司的信息，在建立一个员工表存储员工的信息，在员工表中设置公司ID建立一对多（一个公司对应多个员工）的对应关系，而不是用一张表存储公司和员工的信息，这样会造成公司的信息冗余。

第三范式：每一张表的每一个字段都是应该和主键直接相关的，主要目的也是为了防止冗余，但是在实际情况下可能会经常违背第三范式。例如在员工信息表中，存储着公司ID，但是加了一个<公司名称>字段，这样做的好处是查询时候不需要关联公司名称，直接查询即可；但是有个明显的缺点是更新麻烦，在公司名称替换的情况下，还要更新用户信息表中的公司名称，若其他表中也是这样设计也都需要更改。这时候就需要根据实际的情况，判断使用哪种方式可以减轻工作量。

三大范式只是一种设计原则，并不一定要完全遵循，需要根据业务情况和工作量进行考量。

【数据库设计常见注意事项】

（1）命名规范：a.前缀_ 分模块清楚b.大写字母开头c.英文单词命名；

（2）自增id和GUID的主键问题，自增id：占用空间小，可能会有业务意义，比如系统升级改版后数值大于1000w都是新用户，多库环境、不同环境的数据库id冲突，不利于分布式存储

　　　　　　　　　　　　　　　GUID：程序生成，全球唯一，插入数据库，不会错误的join，方便导入数据，但是占用空间多，本身没有什么含义，不能建立聚集索引。

（3）外键：在本表不是主键而在关联表示主键，外键可以做数据校验、级联删除，适合于有严格数据关系的时候使用；缺点：导入数据麻烦、增删改的时候会多一步检查的操作。

（4）触发器尽量不要用；存储过程尽量少用。大量复杂的逻辑甚至计算可以用，否则用程序来完成；视图有需要就用，在业务复杂需要查询多个表时可以用；函数不太推荐使用，函数使用不到索引。

（5）字段类型的选择

（6）字段可空：数值类型不要可NULL，in和not in查询会没有结果，一般给个默认值；其他的还是可以的；

（7）统计字段：业务表中可加入CreateTime、CreateId、IsEnable等字段，便于数据跟踪；

（8）软删除：假删除，及把状态改为删除而不是物理删除，若有外键则不能实现假删除；