什么是三大范式:
第一范式:当关系模式R的所有属性都不能在分解为更基本的数据单位时,称R是满足第一范式的,简记为1NF。满足第一范式是关系模式规范化的最低要求,否则,将有很多基本操作在这样的关系模式中实现不了。
第二范式:如果关系模式R满足第一范式,并且R得所有非主属性都完全依赖于R的每一个候选关键属性,称R满足第二范式,简记为2NF。
第三范式:设R是一个满足第一范式条件的关系模式,X是R的任意属性集,如果X非传递依赖于R的任意一个候选关键字,称R满足第三范式,简记为3NF.
第一范式
1、每一列属性都是不可再分的属性值,确保每一列的原子性。
2、两列的属性相近或相似或一样,尽量合并属性一样的列,确保不产生冗余数据。
第二范式
每一行的数据只能与其中一列相关,即一行数据只做一件事。只要数据列中出现数据重复,就要把表拆分开来。
一个人同时订几个房间,就会出来一个订单号多条数据,这样子联系人都是重复的,就会造成数据冗余。我们应该把他拆开来。
第三范式
数据不能存在传递关系,即每个属性都跟主键有直接关系而不是间接关系。像:a–>b–>c 属性之间含有这样的关系,是不符合第三范式的。
比如Student表(学号,姓名,年龄,性别,所在院校,院校地址,院校电话)
这样一个表结构,就存在上述关系。 学号–> 所在院校 --> (院校地址,院校电话)
这样的表结构,我们应该拆开来,如下。
(学号,姓名,年龄,性别,所在院校)–(所在院校,院校地址,院校电话)
数据库设计最重要的是看需求跟性能,需求>性能>表结构。所以不能一味的去追求范式建立数据库。
1.表及字段的命名规则
(1).可读性原则:使用大小写来格式化的库对象名字以获得良好的可读性。例如:使用custAddress而不是custaddress来提高可读性。
(2).表意性原则:对象的名字应该能够描述它所表示的对象。例如:对于表,表的名称应该能够体现表中存储的数据内容;对于存储过程,存储过程应该能够体现存储过程的功能。
(3).长名原则:尽可能少使用或者不使用缩写,适用于数据库(DATABASE)名之外的任一对象。
2.数据库字段类型选择原则
1.列的数据类型一方面影响数据存储空间的开销,另一方面也会影响数据查询性能。当一个列可以选择多种数据类型时,应该优先考虑数字类型,其次是日期或者二进制类型,最后是字符类型。对于相同级别的数据类型,应该优先选择占用空间小的数据类型。
2.以上选择原则主要是从下面两个方面考虑。
(1)在对数据进行比较(查询条件、JOIN条件、排序)操作时:同样的数据,字符处理往往比数字处理慢。
(2)在数据库中,数据处理以页为单位,列的长度越小,利于性能提升。
3.char与varChar如何选择
1.如果列中要存储的数据长度差不多是一致的,则应该考虑用char;否则应该考虑用varChar。
2.如果列中的最大数据长度小于50byte,则一般也考虑用char(如果这个列很少用,则基于节省空间和减少I/O的考虑,还是可以选择用varChar)。
3.一般不宜定义大于50byte的char类型列。
4.decimal与float如何选择
1.decimal用于存储精确数据,而float只能用于存储非精确数据。故精确数据只能选择用decimal类型。
2.由于float的存储空间开销一般比decimal小(精确到7位小数只需要4个字节,而精确到15位小数只需要8字节)故非精确数据优先选择float类型。
5.时间类型如何存储
1.使用int来存储时间字段的优缺点
(1)优点:字段长度比datetime小。
(2)缺点:使用不方便,要进行函数转换。
(3)限制:只能存储到2038-1-19 11:14:07 即:2147483648。
2.需要存储的时间粒度
年、月、日、小时、分、秒、周
6.如何选择主键
1.区分业务主键与数据库主键
(1)业务主键用于标识业务数据,进行表与表之间的关联。
(2)数据库主键为了优化数据存储(Innodb会生成6个字节的隐含主键)。
2.跟踪数据库的类型,考虑主键是否要顺序增长,有些数据库是按主键的顺序逻辑存储的。
3.主键的字段类型所占空间要尽可能的小,对于使用聚集索引方式存储的表,每个索引后都会附加主键信息。
7.避免使用外键约束
1.降低数据导入的效率。
2.增加维护成本。
3.虽然不建议使用外键约束,但是相关联的列上一定要建立索引。
8.避免使用触发器
1.降低数据导入的效率。
2.可能会出现意想不到的数据异常。
3.使业务逻辑变得复杂。
9.关于预留字段
1.无法准确的知道预留字段的类型。
2.无法准确的知道预留字段中所存储的内容。
3.后期维护预留字段所要的成本,同增加一个字段所需要的成本是相同的。
4.严禁使用预留字段