单机数据库的表格设计模式（范式设计）

单机数据库的表格设计模式

1、范式设计
早期数据库使用都是单机.如果用户量不大,访问并发不特别高,但是硬盘成本比较高,一般都会使用三范式设计模式来设计表格—节省空间,牺牲时间(查询需要大量的关联) 。
三范式
❤第一范式：表格设计不能出现可以拆分的字段
id location phone name
1 北京 69887656,13309987653 王翠花
2 上海 88765328,11330099887 刘首付

不满足第一范式,phone可以拆分成2个字段 座机/手机.在关系型数据库中自动满足第一范式
id location mobile phone name
❤第二范式：所有非主键字段,必须依赖全部的主键字段.
依赖：字段存在的意义,取决于某一个其他字段.
学生成绩记录表格
select * from score where stu_id and class_id

每一行都表示某个学生的某一课的成绩相关信息, stu_id class_id复合主键使用

stu_score 依赖全部的主键字段 stu_id class_id同时存在 得分才有意义
stu_name 依赖部分主键 stu_id
class_name 依赖部分主键 class_id
严格按照范式设计第二范式,需要将这个表格拆分,最终从多个表格查询成绩信息,势必要进行关联查询
studeent
stu_id stu_name
class
class_id class_name
score
stu_id class_id stu_score

select * from student s inner join score r on r.stu_id=s.stu_id inner join …
❤第三范式：非主键字段,必须依赖主键字段,不能依赖非主键字段

学生信息(大学)
stu_id apa_id apa_name stu_name
1 aaa 物理学院 王翠花

学院名称 apa_name并不依赖主键字段,而是依赖一个非主键字段apa_id
为了满足第三范式,需要拆分
stu_id apa_id stu_name

apa_id apa_name

总结:
非主键字段依赖主键字段.
如果是复合主键,必须全部依赖.
目的：牺牲时间,节省空间(范式拆分之后,绝对不会出现冗余字段)

user_id product_id:第二范式违反.
num:依赖全部主键字段
product_price
prodct_name
product_image

id:主键 每一个id都表示一个购物车的数据
user_id:依赖主键
product_id:依赖主键
num:依赖主键
荣誉字段
※ 反范式
违反三范式设计,会出现冗余字段,牺牲空间,节省时间.

2、单机数据库的瓶颈
设计单机数据库模式如何巧妙也无法避开单机性能的瓶颈
△磁盘读写数据:io的速度瓶颈 现代机械磁盘 读写速度 200MB/S
在并发如此之高的今日,这些效率还不够,需要引入分布式,容量
△单机故障问题无法解决:数据库的数据是最终的数据来源.尽可能保证高可用.