数据库设计三范式
有下划线的代表是主键
1. 确保列的原子性
所有字段都是不可分解的原子值
用户表:
不存在多个收货地址的需求...懒得搞了
| 用户 ID | 用户名称 | 联系电话 | 会员级别 | 收货地址 | 积分 |
|---|---|---|---|---|---|
| 888 | 张三 | 17612341234 | V1 | 上海市崇明县新村乡新卫村 XXX 号 | 666 |
假设收货地址这个列, 我们经常需要用到地址中城市的数据, 这种时候应该把城市提取出新的列,或者干脆把地址拆成 省, 市, 区, 详细地址 四个列
(修改成如下)
| 用户 ID | 用户名称 | 联系电话 | 会员级别 | 省 | 市 | 区 | 详细地址 | 积分 |
|---|---|---|---|---|---|---|---|---|
| 888 | 张三 | 17612341234 | V1 | 上海市 | 上海市 | 崇明县 | 新村乡新卫村 XXX 号 | 666 |
2. 确保列与主键相关
就是要有主键,并且每列都和主键相关,而不是部分主键相关(复合主键中的某一个)
举例如下:
用户表为范式一的用户表
订单表:
| 订单 ID | 商品 ID | 商品名称 | 商品价格 | 数量 | 用户 ID | 用户名称 | 联系电话 | 收货地址 |
|---|---|---|---|---|---|---|---|---|
| 1 | 2 | 奥特曼 | 100 | 1 | 888 | 张三 | 17612341234 | XXXXXXXX |
| 1 | 3 | 怪兽 | 200 | 1 | 888 | 张三 | 17612341234 | XXXXXXXX |
(订单 ID 和商品 ID 是复合主键)
上面这张表也能完成订单的效果, 但是他违背了第二范式 商品名称, 商品价格 只和 商品 ID 相关 不和 订单 ID 相关
(订单表拆成如下:)
订单表:
| 订单 ID | 总价格 | 用户 ID | 用户名称 | 联系电话 |
|---|---|---|---|---|
| 1 | 300 | 888 | 张三 | 17612341234 |
商品表:
| 商品 ID | 商品名称 | 商品价格 |
|---|---|---|
| 2 | 奥特曼 | 100 |
| 3 | 怪兽 | 200 |
订单商品表:
| ID | 订单 ID | 商品 ID |
|---|---|---|
| 1 | 1 | 2 |
| 2 | 1 | 3 |
3. 确保每列的值都和主键直接相关, 而不是间接相关
简单来说就是减少冗余字段
前面范式二 最后的订单用户名称, 联系电话 ,收获地址=在用户表中已经存在了, 不应该冗余, 只要有下单的用户 ID 就行了
反范式:
由于目前流行微服务架构 比如订单服务, 商品服务,用户服务完全是 3 个服务,数据库是独立的, 所以不一定需要根据数据库三范式设计数据库,
还有一个原因是因为现在的互联网公司数据量庞大, 导致会分库分表, 所以不适合连表查询, 最后反而会搞很多冗余数据, 来减少连表查询, 当然 最重要的原因其实是因为(硬盘不值钱,便宜)
欢迎来到这里！
我们正在构建一个小众社区，大家在这里相互信任，以平等 • 自由 • 奔放的价值观进行分享交流。最终，希望大家能够找到与自己志同道合的伙伴，共同成长。
注册 关于