数据库设计

标签：bubuko   change   拆分   自定义   from   技术分享   系统   矩形   border   

………………………………………………………………………………………………

数据库设计步骤 ： 需求分析 => 逻辑设计 => 物理设计 => 维护优化

【数据需求分析】

1.什么数据

2.属性（字段）

3.数据和属性有哪些特点

【逻辑设计】

1.E-R 图

【物理设计】（mysql pgsql）

【维护优化】

1.新需求建表

2.索引

3.大表拆分

【需求分析】

1.数据生命周期

2.实体和实体 之间关系

3.实体属性是什么 （设计属性诀窍我个人理解 核心是业务要成功 面向的两个对象是 人和机器）

4.哪些属性或 属性的组合 可以标识唯一性。

…………………………………………………………………………

【需求分析实际例子】

注册用户模块

1.【用户】用户名、密码、姓名、身份证号、联系方式、联系地址 => 标识唯一 用户名、身份证号、邮箱、手机号（生命周期永久）

购买商品模块

2.【商品】商品编码、商品名称、商品描述、商品品类、供应商名称、有效期、价格 => （商品名称+供应商名称）、商品编码

　　（生命周期：对下线的商品可以归档操作）

订单详情模块

3.【订单】订单号、用户姓名、用户电话、收货地址、商品编号、商品名称、数量、价格、订单状态、支付状态、订单类型

　　=> 标识唯一 订单号  （生命周期：分表存储 + 分库存储）

购物车模块

4.【购物车条目】用户名、商品编号、商品名称、加入时间、商品数量 => （用户名、商品编号、加入时间）（购物车条目编号）

 => 设置 清理规则 可以归档。

供应商模块

5.【供应商】供应商编号 供应商名称 联系人 电话 营业执照 地址 法人 => 供应商编号、营业执照编号 （生命周期：永久）

按业务（经验主义）去理解实体之间关系 

用户 购物车条目 1...M

用户 订单条目 1...M

订单 商品 M...N

供应商 商品 M...N

购物车 商品 M...N

…………………………………………………………………………………………………………………………

【逻辑设计阶段】接口继承需求分析，产出：E-R图。

1.关系 = 表

2.元组 = 表的一行

3.属性 = 字段

4.候选码 = 可标识元组唯一的属性组合

5.主码 = 主键

6.域 = 取值范围 = 约束

7.分量 = 元组中一个属性值 

1）矩形 = 实体

2）菱形 = 关系

3）椭圆 = 属性

【数据库设计范式】

1 范 二维表

2 范 context + 主键 => 解决大部分依赖

3 范 关系表 + 外键  => 现实开发需要违反这个范式，用空间换取时间，适当数据冗余快速 Select 少掉 Join 过程。

BC范式 - 组合型候选主键之间不能依赖。 

4、5 BC范式

【数据操作异常】第二范式 

1.插入异常 省略所依赖的实体报错

2.更新异常 单独更新某个实体单个属性发现要更新多行

3.删除异常 删除一个实体导致另一个实体丢失。

【数据冗余】第二范式

某个列可以通过其他列计算得出。

【反范式】第一 第二 范式，违反第三范式。

用空间换取时间，适当数据冗余快速 Select 少掉 Join 过程。

1.减少表的关联数量

2.增加表读取效率

3.适度增加数据冗余 对机器伤害 对用户友好，何乐而不为？

…………………………………………………………………………………………………………………………

【物理设计】

1.选择数据库管理系统

2.定义数据库、表、字段的命名规范

3.具体 DBMS 调整字段类型

【Mysql 存储引擎】

………………………………………………………………………………………………………………………………

【表字段命名规范】

给人读的，表名称要体现 context_xxx ，是表就让它【体现存什么】，是存储过程就让它【体现功能是什么】

【表数据类型】https://dev.mysql.com/doc/refman/5.7/en/data-types.html

Char(10) ‘2018-05-11‘

Varchar(32) ‘2018-05-11‘

Datetime 2018-05-11

Int 1900年（未求证）至今逝去的毫秒数字值

存储空间占用：数字 < 日期或二进制 < 字符 

……………………………………………………………………………………………………………………………………

【选择字段数据类型依据】

1.涉及数据比较（排序、查询条件、Join条件），字符处理比较慢于数字处理

2.数据处理以【页】为单位，列长度小，性能则提升。 => Char(M<50) Varchar(L) 都需要注意

decimal 适用于精确 一般到15位小数  8字节  

float 适用于非精确 一般到7位小数   4字节

int 作为时间存储类型缺点，需要函数转换、只能存到2038年-1-19 11:14:07 = 2^32 

现实世界要存 年月日时分秒 周

【如何选择主键】

业务主键 标识业务数据，建立表于表的关系

数据库主键  针对机器优化存储，比如 Innodb 生成6个字节的隐含主键。

注意事项 主键字段类型所占存储空间尽可能小 如何使用【聚集索引，每个索引后自动添加主键信息】（实际上线项目用 Varchar(32)）

【应避免使用外键】

1.降低数据导入的效率

2.增加维护成本

3.但是要记得给【相关联的列添加索引】

【应避免使用触发器】

1.降低数据导入的效率

2.可能出现数据异常，出乎意料...

3.关键是 业务逻辑 变得复杂。

【不要去使用预留字段】计算机应该是明确的。

1.无法准确知道预留字段类型

2.无法准确知道内容

3.后期维护成本 预留字段 = 有这个字段 生命周期：整个应用项目

……………………………………………………………………………………………………………………………………………………………………………………………………

【日常维护数据库，发现就要优化】

1.维护数据字典（先前规范定下来，每个字段的含义是什么）

2.维护索引

3.维护表结构

4.适当的拆分 

【数据字典】

1.使用第三方工具 

2.MySql Comment ‘字段含义‘

导出数据字典 查看 ‘customer‘ 含义，这样我们就知道字段在【几张关联表中各自表达的含义】

Select
a.table_name , b.table_comment , a.column_name,
a.column_type , a.column_comment
From
information_schema.columns a 
Join
information_schema.tables b
On 
a.table_schema = b.table_schema and a.table_name = b.table_name 
Where
a.table_name = ‘customer‘

【如何维护索引】

1.出现在 Where 、Group by 、Order by 的列

2.索引不是越多越好，过多降低读和写效率

3.SQL语句不要使用强制索引关键字 （mysql不合适）

4.不要使用全文索引

【如何维护表结构】同时要记得维护数据字典

Mysql55 使用 pt-online-schema-change

Mysql56 使用 内建的

【建议】

1.限制 用户使用自定义函数

【表的垂直（按列）拆分】

1.经常查询的列放在一起

2.text blob 大字段放到附加表

【表的水平拆分】大表数据拆成几份小表数据 用 Hash 散列表 管理。

…………………………………………………………………………………………………………………………………………

………………………………………………………………………………………………………………6

数据库设计

标签：bubuko   change   拆分   自定义   from   技术分享   系统   矩形   border   

原文地址：https://www.cnblogs.com/chenhui7373/p/9026134.html