1配置文件
数据库设计(Database Design )是指数据库和在数据库领域中，经常将使用数据库的各种系统统称为数据库APP应用系统。
数据库设计的设计内容包括需求分析、概念结构设计、逻辑结构设计、物理结构设计、数据库实施和数据库运行与维护。
2数据库建模5首歌
3需求汇总
课程属性：{主题、副标题、方向、分类、难度最新热潮、时间长短、个人资料、人数、所需知识、收获、讲师姓名讲师职位、课程图像综合评价、内容实用、简洁易懂、逻辑清晰
课程列表属性：{章名、小节名、说明、小节长度、章URL、视频格式}
讲师属性：{ )讲师昵称、说明、性别、省、市、职位说明、经验、积分、关注人数、关注人数) ) )。
问答q&； a注释属性：{ (类型、标题、内容、相关章节、浏览数量、发布时间、用户昵称)。
笔记属性：{ (用户昵称、相关章节笔记标题、笔记内容、发布时间)。
用户属性：{用户昵称密码、说明、性别、省、市、职位、说明、经验、积分、粉丝数}
评价的属性：{ (用户、课堂主题、内容、综合评价、内容实用、简洁易懂、逻辑清晰、发表时间) }。
4宽工作台模式
百度百科的定义
正如文字所示，是字段多的数据库表。 通常是指与业务主题相关联的指标、维和属性相关联的数据库表。 由于不同的内容都存储在同一个表中，宽表已经不符合三范式的模型设计规范，带来的主要缺点是数据的大量冗馀，相应的优点是查询性能的提高和方便。 这种宽表的设计广泛应用于数据挖掘模型训练前的数据准备，将相关字段放在同一张表中，可以大大提高数据挖掘模型训练过程中迭代计算时的效率问题。
课程属性：{主题、副标题、方向、分类难度最新、最热、最长、个人资料、人数、所需知识、收获、讲师姓名、讲师职位、课程图像综合评价、内容实用、简洁易懂、逻辑上讲
实例
4.1模式问题
4.1.1更新异常
更改一行列中的值会同时更改多行数据
例如使用时
如果想修改职位，不仅仅是一个数据
那么，再加上一个限定条件吧
因为只能修改一行数据，所以主标题可以是数据表的唯一标识符，也就是主键
通过主键更新数据，虽然可以避免数据的更新异常，但也有可能导致表中的数据不一致。 例如，在本例中，讲师的作用产生多义性。
4.1.2插入异常
由于没有主键信息，某些数据无法写入表中
例如，您想要添加Java开发方向的课程
执行此语句时，PK为空。 也就是说，语句不会成功，因为PK不为空且违反了唯一约束。
4.1.3消除异常
删除一个数据的时候必须删除另一个数据
例如，假设您想要删除数据库的方向
我们只是想删除数据库的方向，但是这个句子删除了很多课程。 这不符合我们的期望。
4.1.4数据冗馀
同一数据在一个表上出现了多次
那么，这么多问题是否意味着哪里都没有宽表呢？ 存在是合理的！
4.2模式的适用场景
应用存储在列中的数据报表
在宽表中，所有数据都存在于一个表中，因此查询不需要查询多表，SQL执行效率高，在报表APP应用程序中不是大问题
宽表不适合我们现在的业务，怎么找合适的方法？
5数据库设计范式
5.1第一范式
表中的所有字段都不能重新拆分
例如，以下示例中的联系人是复合属性，明显违反了此范式，无法在数据库中分离
我们只要简单地更改那个就可以了
也就是标准的二维表。
5.2第二范式
前提条件
标准二维表，即第一范式成立
表中存在业务主键，非主键必须依赖于所有业务主键
例如，以下博客表的例子
可以将用户字段用作PK吗？
很明显，单列字段PK处于禁用状态，因为一个用户支持多个博客记录，章标题也可以为多个用户编辑
使用的复合PK
然而，用户点字段仍然不适合第二范式，因为它仅依赖于用户字段，而不依赖于整个PK
将依赖字段拆分为单独的表
从上面可以看出：
如果表中的PK只包含一个字段，则它原本符合第二范式
如果由多个字段组成，则必须考虑是否符合第二范式
5.3第三范式
表中的非主键列不能相互依赖
让我们来看看课程体系
首先，一个场的PK明显适合第2范式，大部分场也只依赖PK，但对于讲师的作用场实际上依赖于讲师名称，因此不适合第3范式。
不与PK形成依存关系的字段直接提交到单独的表中即可
6课程实体的逻辑建模
>属性
{主标题,副标题,方向,分类,难度,最新,最热,时长,简介,人数,需知，收获,讲师名讲师职位,课程图片综合评分,内容实用,简洁易懂,逻辑清晰}
我们显然可以将其拆分如下:
课程表
主标题(PK),副标题,方向,分类,难度,上线时间,学习人数,时长，简介,需知,收获,讲师昵称,课程图片,综合评分，内容实用,简洁易懂,逻辑清晰
讲师表
讲师名及讲师的职称
其中最新属性即对应着上线时间计算得出,业务上可规定时间段判断是否为最新
最热属性即可以学习人数字段排序来反映
课程方向表
课程方向名称(PK) : 在课程表中有对应的方向字段
添加时间
课程分类表
分类名称(PK) : 在课程表中有对应的方向字段
添加时间
课程难度表
课程难度(PK) : 在课程表中有对应的方向字段
添加时间
7 课程列表实体的逻辑建模
属性
[冷静的菠萝,小节名](联合PK)
说明,小节时长，章节URL,视频格式
其中,说明其实只依赖于冷静的菠萝
小节时长，小节URL,视频格式都只依赖于小节名
违反第二范式,所以需要拆分字段
课程章节表
冷静的菠萝(PK),说明,章节编号
课程与章节的联系表
主标题,冷静的菠萝
课程小节表
小节名称(PK),小节视频url,视频格式,小节时长,小节编号
课程章节与小节的联系表
主标题,冷静的菠萝,小节名
8 讲师实体的逻辑建模
属性
讲师名,密码,性别,省,市,职称,说明,经验,积分,关注数,粉丝数
讲师表
讲师名(PK),密码,性别,省,市,职称,说明,经验,积分,关注数,粉丝数
9 用户实体的逻辑建模
属性
用户昵称，密码，性别，省市,职位,说明,经验，积分,关注数,粉丝数
用户表V1.0
用户昵称(PK)，密码，性别，省市,职位,说明,经验，积分,关注数,粉丝数
和讲师表基本相同,且讲师其实也是一种用户,讲师的信息就会被存储两次,造成数据的冗余.,于是就难以保持数据一致性!考虑合并!
用户表V2.0
用户昵称(PK)，密码，性别，省市,职位,说明,经验，积分,关注数,粉丝数,讲师标识
10 问答评论实体的逻辑建模
属性
类型,标题,内容关联章节,浏览量,发布时间,用户昵称
其中标题文字是共享的,无法保持一致
同一用户在不同章节提出的问题也可能相同
因此决定采用标题+用户昵称+关联章节作为PK
评论表
如何记录关联章节字段呢?
是不是只能用课程章节的PK来记录呢?
因此,不得不将课程章节的关联表PK加入
[标题,课程主标题,课程章名,小节名称,用户呢称](PK)
父评论(被回复的问题/标题)
标题,内容,类型,浏览量,发布时间
11 笔记实体的逻辑建模
属性
用户昵称,关联章节,笔记标题,笔记内容，发布时间
和评论实体差不多,分析不再赘述
笔记表
[笔记标题,课程主标题,课程章名,小节名称,用户呢称](PK)
内容,发布时间
12 评价实体的逻辑建模
属性
用户呢称;课程主标题,内容,综合评分,内容实用,简洁易懂,逻辑清晰，发布时间
评价表
[用户呢称;课程主标题](PK)
内容,综合评分,内容实用,简洁易懂,逻辑清晰，发布时间
只有选择/购买了课程的用户才能评价!!!
需要用户与所选课程的关联关系表
用户选课表
[用户呢称;课程主标题](PK)
选课时间,累积听课时长
13 小结
14 范式化暴露的问题
如果我们想要查询出一门课程包括所有章节和小节的相关信息
那么这些信息又是如何存储的呢,需要查询哪些表呢?如下所示
我们就要关联5个表,查询效率极低!且查询课程信息的需求很大!
为了提高性能,我们还需要对表结构进行优化操作
15 反范式化设计
空间换时间的思想
15.1 课程章节表反范式化设计
上述表存在一对多的关系
所以可以并不需要关联关系表,而是呢可以直接把课程表和课程&章节联系表合并
成为新的课程章节表
[主标题,冷静的菠萝](PK),说明,章节编号
虽然违反了第二范式,但是减少了一个表的查询,提高了查询性能,在频繁查询操作的系统中,这很值得!
经过反范式化后,我们只需要查询三个表即可
15.2 反范式化设计小结
课程相关表数量 5 -> 3
16 常用存储引擎
17 InnoDB存储引擎的特点
事务型存储引擎支持ACID
数据按主键聚集存储
支持行级锁及MVCC
支持Btree和自适应Hash索引
支持全文和空间索引
18 根据 InnoDB特性优化后的表逻辑结构
通过数据冗余避免数据不一致
课程章节表:{章节ID(PK),课程ID，冷静的菠萝称,章节说明,章节编号}
课程小节表:{小节ID(PK),课程ID,章节ID,小节名称,小节视频url,视频格式，小节时长,小节编号}。
课程方向表:{课程方向ID(PK),课程方向名称,填加时间}
课程分类表:{课程分类ID(PK),分类名称,填加时间}
课程难度表:{课程难度ID(PK) ,课程难度，填加时间}
用户表:{用户ID(PK)，用户昵称,密码，性别，省市,职位,说明，经验,积分,关注
人数,粉丝人数,讲师标识}
问答评论表:{评论ID(PK),父评论ID ,课程ID，章节ID,小节ID ,评论标题,用户
ID,内容,类型,浏览量,发布时间}
笔记表:{笔记ID(PK),课程ID,章节ID,小节ID笔记标题,用户呢称,笔记内容,
发布时间}
评价表:{评价ID(PK)，用户ID,课程ID,内容综合评分,内容实用,简洁易懂,逻
辑清晰,发布时间}
用户选课表:{用户选课ID(PK),用户ID,课程ID,选课时间，累积听课时长}
19 常用的整数类型
20 常用的浮点类型
例如:
实战实数类型的特点
建立测试数据库
新建表
插入数据至t表中
查询和
和的结果
所以只有decimal是精确的浮点类型
21 常用的时间类型
实战时间类型的特点
新建表
插入数据
查询结果
由于北京时间是东八区,因此我们更改时区
新的查询结果
这就是timestamp具有时区性的特点
22 字符串类型的特点
23 如何为数据选择合适的的数据类型
23.1 优先选择符合存储数据需求的最小数据类型
INET_ATON( '255.255.255.255' ) = 4294967295
INET_ NTOA(4294967295) ='255.255.255.255'
23.2 谨慎使用ENUM,TEXT字符串类型
23.2.1 ENUM 的迁移
数据迁移的时候，它几乎不可能被其他数据库所支持，如果 ENUM 里面是字符串，对于其他数据库来说就更郁闷了，还不能设为tinyint等类型的字段
23.2.2 ENUM 的索引
纯数字类型的不建议用枚举类型，这是因为在 ENUM 内部维护有一个隐形的索引，也是按数字排列的，容易混淆；添加枚举值也是一个问题，如果添加在最后还好，如果添加在中间什么位置的话，原来的隐藏索引将不再起作用
23.2.3 ENUM 字段 的NULL 值
ENUM 字段默认是可以插入 NULL 值的，这个就比较尴尬了，而且没有办法优化
23.2.4 插入的值
如果插入的值比ENUM设定的值大，会默认保存成接近的那个值；插入的值不能包含函数，不能传递参数
所以如果插入的值是数字型的，建议用tinyint，如果插入的值是字符型的，建议用char。如果真想用 ENUM 也是可以得，前提是要了解到 ENUM 的弊端，就可以有效规避这些问题
23.4 同财务相关的数值型数据,必需使用decimal类型。
24 为项目表们选择合适的数据类型
24.1 课程表
24.2 章节表
24.3 小节表
24.4 课程分类表
24.5 课程难度表
24.5 课程方向表
24.6 用户表
24.7 问答评论表
24.8 笔记表
24.9 用户选课表
30 如何为表和列选择合适的名字
所有数据库对像名称必须使用小写字母可选用下划线分割
所有数据库对像名称定义禁止使用MySQL保留关建字
数据库对像的命名要能做到见名识义,并且最好不要超过32个字
临时库表必须以tmp为前缀并以日期为后缀
用于备份的库,表必须以bak为前缀并以日期为后缀
所有存储相同数据的列名和列类型必须一致。
31 总结
工程师的必备技能
1、前奏：【业务分析】欲善其事，必三思而行；
2、高潮：【逻辑设计】范式化VS反范式化；
3、结束：【物理设计】存储引擎&数据类型&命名规约。
内容综述
数据库的逻辑设计规范
MySQL的常用存储引擎及其选择方法
MySQL的常用数据类型及其选择方法
如何为表选择适合的存储类型
如何为表起一个好名
参考