数据库设计小经验

      数据库设计在一个项目总占有非常大的比重，如果设计的不好、不合理，在后面开发过程中做改动会对项目产生非常大的影响，会浪花很多时间，一下是在开发过程中总结出的一些小经验：

 

1、对于一对一关系的实体，用一张表表示。

 

2、对于一对多的实体，用两张表表示，而且“多”的那张表中做一个指向“一”表中主键的外键。

 

3、对于多对多的实体，在两张表中间加一个关系表，建两个外键字段，分别指向两个“多”的表，这两个外键可以联合在一起作为关系表的主键，也可单独加一个字段，用于主键。

 

4、几个字符的长度，可以采用char；几十、几百或上千的字符串可以用varchar，同时建议用nvarchar(nvarchar不考虑中英文，长度1就是一，二就是2，在程序限制最大长度时，方便)；大文本时用text(少用)。现实问题：①、注意oracle同一种数据类型比如varchar2，在不同“字符集”的数据库中，能存储的内容长度是不一样的，一个汉字占两个长度、、四个长度都是有可能，需要注意，不然开发时正常，上线内容就超出字段存储长度而存不进去。

 

5、对于有限值的字段(如性别)，可以用数字和英文，不建议用中文，防止乱码(程序或数据库)后很难恢复、为后期维护带来不必要的麻烦。现实问题：①、如果没有特殊需要，直接用对应的汉字名称也是不错的选择，这样在编辑、保存、展示等等的地方都不需要做额外的转换。

 

6、尽量少用数据库的约束(主键要用，其他：如外键、非空、唯一建议不用)，转而采用程序来控制，过多的约束影响数据库性能和数据的转储。

 

7、数据库主键可以使用本身有意义的字段，也可单独建一个主键字段，但是建议单独建立主键字段，并采用UUID等各种主键生产策略，通过程序产生存入进去，而不是用数据库的自增策略产生。现实问题：①、这样在后期如果存在换库、移植到其他数据库方便(如从MSSQL到Oracle等)，另外当移植到一个新的数据库时(换机子、库挂了重新创建等)存在自增主键与现有主键冲突(自增又从0开始，这样新自增值会与已有的主键值重复)，③、用单独的主键值不需要考虑具体业务，特别是在表中没有唯一性字段时，可避免组合主键带来的操作不便和性能下降(不过需要牺牲部分空间存储无实际意义的主键值)，④、主键值生成策略除了UUID外，还有一个好的建议：yyMMddHHmmssSSS+随机数（根据系统具体需要：年可选1到4为，一般2位足够，随机数：可自定位数），这样使用数字可提高查询性能(数据库擅长处理数字)，比UUID长度短，还有可存储有意义的当前记录创建时间信息。

 

8、数据库表名、字段名尽量使用有意义的英文或中文拼音(或其缩写)来表示，多个单词组成时，应该使用下划线分隔，而不应该采用java方法名的命名规则(第一个单词首字母小写，其他单词首字母大写)。现实问题：①、因为有的数据库、程序、存储过程区分大小写，而有的不区分大小写，②、有的数据库将所有字母改为大写，比如oracle。

 

9、切记不要使用数据库的关键字或保留关键字作为数据库表名、字段名，如果系统后期可能跨库，则要多种数据库考虑，否则只需考虑当前数据库，加下划线是一个不错的选择，现实问题：①、有的数据库sql中带关键字报错，特别是oracle。

 

10、同库中的表字段尽量少出现同名，现实问题：①、查询时为区分需要起别名，②、系统代码中不好辨认，有时二字段同时存在在一个业务中时处理麻烦。

 

11、数据库中尽量使用数字或者不是很长的字符串作为主键，防止大数据量处理时，速度过慢。

 

12、每一张表总留几个备用字段，最好留一个数字类型的，留几个字符串类型的，防止以后维护时要扩充字段，而客户已经使用的数据库中又没有可用的备用字段时，此时修改客户数据库结构，比较麻烦。

 

13、多表之间的关联查询，必要时考虑用视图，但视图尽量不要嵌套。现实问题：①、sql太长充斥在代码中难维护。

 

14、涉及多表直接的关联计算、插入可以考虑使用存储过程(数据量大时)，以提高性能，尽量避免使用存储过程，以方便后期的数据库移植。

 

15、尽量少使用某一种数据库独有的功能，如(MSSQL的top等)，以方便后期系统移库。

 

16、在不能完全确定某一个字段的取值就是数字时，请使用字符串（如机构代码，有的就直接用数字，但是后期如果客户机构编码中出现了字符串，则要修改字段类型，而机构表如果与系统中其他模块关联比较多，则都得改，数据库一改，意味着程序的大量修正，你会疯的）。

 

17、尽量不要使用某一数据库独有的数据类型，如boolean，在实际当中也不建议使用boolean类型，必要时请换成数据类型或字符串类型。

 

18、如果数据库表关联比较复杂，设计时要考虑存储一些重复的冗余字段，减少查询时的关联操作。