赞
踩
有效的存储
高效的操作
插入异常:如果某个实体随着另一个实体的存在而存在,即缺少某个实体无法表示这个实体,那么这个表就存在插入异常
更新异常:如果更改表的某个单独属性时,需要更新多行数据,那么这个表存在更新异常
删除异常:如果删除表的某一行来反映实体失效时导致另一个不同实体实例信息丢失,那么这个表中就存在删除异常
数据冗余:相同的数据在多个地方存在,或者说表中的某个列可以由其他列计算得到,那么这个表就存在数据冗余
PS:一般存在插入异常的表都存在更新异常和删除异常
用ER图表示表与表之间的对应关系及表中的字段属性
矩形:表示实体集,代表一张表
菱形:表示表与表之间的联系
椭圆:表示实体的属性
线段:表示对象之间存在关联
第一范式:列不可再分,数据属性尽量拆分到不可再分
第二范式:所有非主键字段只能依赖主键,而不能依赖主键的一部分,即所有的单主键表都满足第二范式
第三范式:非主键字段之间不能相互依赖,如果存在非主键字段之间的依赖,应当拆表
BC范式:联合主键之间的字段不 能相互依赖,如果存在,就不应该使用联合主键。
第四范式:一个表的非主键属性相互独立时,非主键属性不能有多个值。例如,职工表(职工编号,职工孩子姓名,职工选修课程),在这个表中,同一个职工可能会有多个职工孩子姓名,同样,同一个职工也可能会有多个职工选修课程,即这里存在着多值事实,不符合第四范式。如果要符合第四范式,只需要将上表分为两个表,使它们只有一个多值事实,例如职工表一(职工编号,职工孩子姓名),职工表二(职工编号,职工选修课程),两个表都只有一个多值事实,所以符合第四范式。
第五范式:尽可能将表拆分成较小的表,以减少数据冗余
PS: 数据库范式层层往后依赖,即后一范式一定满足前一范式,设计通常满足第三范式即可,越往后付出价值越大,若追求性能,不一定遵循这些范式。
目的:建立数据库的表结构
功能 | MyISAM | Innodb | Memory | Archive |
存储限制 | 256TB | 64TB | RAM | None |
支持事务 | No | Yes | No | No |
支持全文索引 | Yes | Yes | No | No |
支持数索引 | Yes | Yes | Yes | No |
支持哈希索引 | No | Yes | Yes | No |
支持数据缓存 | No | Yes | N/A | No |
支持外键 | No | Yes | No | No |
选择原则:
自增主键:
UUID:
设计原则:
2.3.3 字段类型的选择
1. 根据业务的需要先确定大的字段类型方向,如是使用字符串?还是整形?还是浮点型?还是时间类型。确定后再来细化选择。
2. 如果一个字段既各种类型都可以满足业务需求,优先选择数字类型,其次是时间类型,最后考虑字符串类型。因为相对而言,计算机更擅长数字计算。
3. 在满足业务的前提下尽量使用存储空间较小的数字类型,适当考虑日后数据的增长。如果没有负数,应使用无符号数字类型。
4. 对于有小数的字段,优先考虑decimal定点型,它的精确度更高。但相对于float、double来讲,它的存储空间更大。
5. 日期尽量用日期类型,不要用数字类型,避免带来不必要的麻烦。
更多细节参考:MYSQL字段类型
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。