五、mysql之业务设计

一、逻辑设计

1、范式设计

1.1第一范式

数据库表中的所有字段都只具有单一属性,单一属性的列是由基本数据类型所构成的,设计出来的表都是简单的二维表

1.2第二范式

要求表中只具有一个业务主键,也就是说符合第二范式的表不能存在非主键列只对部分主键的依赖关系
举例来说: 有两张表:订单表,产品表
在这里插入图片描述
在这里插入图片描述
一个订单有多个产品,所以订单的主键为【订单 ID】和【产品 ID】组成的联合主键,这样 2 个组件不符合第二范式,而且产品 ID 和订单 ID 没有强关联,故把订单表进行拆分为订单 表与订单与商品的中间表。
在这里插入图片描述

1.4 第三范式

指每一个非非主属性既不部分依赖于也不传递依赖于业务主键,也就是在第二范式的基础上相处了非主键对主键的传递依赖
在这里插入图片描述
其中
客户编号 和订单编号管理 关联 客户姓名 和订单编号管理 关联 客户编号 和 客户姓名 关联

如果客户编号发生改变,用户姓名也会改变,这样不符合第三大范式,应该把客户姓名这一 列删除

1.5范式设计实战

按要求设计一个电子商务网站的数据库结构

  1. 本网站只销售图书类产品
  2. 需要具备以下功能
    用户登陆 商品展示 供应商管理 用户管理 商品管理 订单销售
    在这里插入图片描述
    查询联系
    编写 SQL 查询出每一个用户的订单总金额(用户名,订单总金额)
    在这里插入图片描述
    问题: 大量的表关联非常影响查询的性能 完全符合范式化的设计有时并不能得到良好得 SQL 查询性能

反范式设计

  • 反范式化是针对范式化而言得,在前面介绍了数据库设计得范式
  • 所谓得反范式化就是为了性能和读取效率得考虑而适当得对数据库设计范式得要求进行违反
  • 允许存在少量得冗余,换句话来说反范式化就是使用空间来换取时间

不能完全按照范式得要求进行设计,考虑以后如何使用表

范式化设计优缺点
优点:
可以尽量得减少数据冗余
范式化的更新操作比反范式化更快
范式化的表通常比反范式化的表更小
缺点:
对于查询需要对多个表进行关联
更难进行索引优化
反范式化设计优缺点
优点: 可以减少表的关联
可以更好的进行索引优化
缺点:
存在数据冗余及数据维护异常
对数据的修改需要更多的成本

二、物理设计

1、命名规范

1.1 数据库、表、字段的命名要遵守可读性原则

使用大小写来格式化的库对象名字以获得良好的可读性 例如:使用 custAddress 而不是 custaddress 来提高可读性。

1.2数据库、表、字段的命名要遵守表意性原则

对象的名字应该能够描述它所表示的对象
例如: 对于表,表的名称应该能够体现表中存储的数据内容;对于存储过程 存储过程应该能够体现存储过程的功能。

1.3数据库、表、字段的命名要遵守长名原则

尽可能少使用或者不使用缩写

2、存储引擎选择

在这里插入图片描述

3、数据类型选择

当一个列可以选择多种数据类型时

  • 优先考虑数字类型
  • 其次是日期、时间类型
  • 最后是字符类型
  • 对于相同级别的数据类型,应该优先选择占用空间小的数据类型
3.1浮点类型在这里插入图片描述
3.2日期类型

timestamp 类型 与 datetime 区别

  • timestamp 和时区有关,而 datetime 无关
    在这里插入图片描述
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值