数据库设计三范式

本贴最后更新于 962 天前,其中的信息可能已经水流花落

数据库设计三范式


有下划线的代表是主键

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 个服务,数据库是独立的, 所以不一定需要根据数据库三范式设计数据库,

还有一个原因是因为现在的互联网公司数据量庞大, 导致会分库分表, 所以不适合连表查询, 最后反而会搞很多冗余数据, 来减少连表查询, 当然 最重要的原因其实是因为(硬盘不值钱,便宜)

  • 数据库

    据说 99% 的性能瓶颈都在数据库。

    330 引用 • 614 回帖 • 1 关注

相关帖子

欢迎来到这里!

我们正在构建一个小众社区,大家在这里相互信任,以平等 • 自由 • 奔放的价值观进行分享交流。最终,希望大家能够找到与自己志同道合的伙伴,共同成长。

注册 关于
请输入回帖内容 ...