9.数据库基础设计与表设计

-1.影响性能

1. 需求变更( 设计的时候可以多考虑 提高 程序 扩展性)
2. 业务架构-程序代码-!-SQL 分层 服务化 微服务服务
3. SQL语句写
4. 数据库设计问题
   4.1. 数据表关系结构 (三大范式)
   4.2. 数据表本身结构 (三大范式)
   4.3. 数据表字段选择 (事先能够对于业务有预计的一些点)

0. 数据库关系数据库

所谓关系数据库就是采用关系模型作为数据的组织方式，换句话说就是支持关系模型的数据库系统。

关系模型由三个部分构成：关系数据结构、关系数据操作和完整性约束。

1. 关系数据结构
    关系模型的数据结构非常简单，实际上就是一张二维表，但这种简单的二维表却可以表达丰富的语义，可以很方便地描述出现实世界的实体以及实体之间的各种联系。

2. 关系数据操作
    关系数据操作采用集合操作方式，即操作的对象和结果都是集合。关系数据操作包括查询和更新两个部分：

3. 完整性约束
    完整性约束条件是关系数据模型的一个重要组成部分，是为了保证数据库中的数据一致性。完整性约束分为三类：实体完整性、参照完整性和用户定义完整性。

1. 三大范式 => 六大范式(1~5NF,BCNF)

在设计关系数据库的时候，一般来说我们都是需要遵从不同的规范要求来设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

范式分为：3大范式，以及BC范式，第四范式还有第五范式 一共六大范式通常来说满足与三大范式就基本足够 ；

注意：项目的数据库设计并不一定要完全满足与三大范式，有些时候我们会适量的冗余让Query尽两减少Join

误区:不是范式越高越就越好  好 => 结构清晰
早期:希望数据可以足够的小 数据量不是问题 主要分问题
现在:希望查询速度越快越好,同时操作越简单越好

1.1 第一范式（1NF）

简单地说，第一范式要求关系中的属性必须是原子项，即不可再分的基本类型，集合、数组和结构不能作为某一属性出现，严禁关系中出现“表中有表”的情况

在任何一个关系数据库系统中，第一范式是关系模式的一个最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。

一句话解释：斤斤计较

针对对象字段：是否可以继续细分

例子：地址

1.2 第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础建立起来的，既满足第二范式（2NF）就必须要满足第一范式。第二范式（2NF）要求实体的属性完全依赖于主键字。

一句话解释：不要拖泥带水

1.3 第三范式（3NF）

第三范式（3NF）是第二范式的子集，既满足第三范式就必须满足第二范式。意思是不存在非关键字段对任意候选关键字段的传递函数依赖

一句话解释：38线 （一山不容二虎）

2. 案例 => 数据表的字段选择

面试 设计一个 登入系统 可以发表文章 类似于csdn

数据库分析及建立流程：

登入系统 => 发表对应文章表 博客 CSDN

功能:

1. 用户可以注册登入
2. 可以发表
3. 有不同的类型用户
4. 根据文章查询某一个用户发表的其他文章
5. 有可能有不同类型的文章

表: 用户表,用户分组,文章,文章分组

对应数据表及其结构：

系统中:一个户登入之后 自己去浏览自己的个人信息 次数不多吧

用户登入系统之后 -> 阅读文章

因为这个博主文章好,会点击博主的头像 会有哪些文章,根据用户的id 查询用户发表文章 然后 在进行排序

user,article

select
  u.id,u.name,a.id,a.subject
from
  user u
left join
  article a on a.user_id = u.id
where
  u.id = ? (代表参数)
order by
  gmt_create
desc limit
  20

2000w => 12s
select count(*) from admin_user;

你可以看到这么点数据量就需要1秒钟还没有关联，如果关联就需要更久的时间。当然可以通过索引优化SQL这是一种方法，实际上也可以从数据库的结构设计出发来优化查询操作。

在这种情况下，我们可以通过设计合适的索引进行优化查询速度，不过也可以通过从数据表的设计上去优化这一块的查询速度

修改之前首先需要分析：

1. 一个这个系统哪一个部分用户操作最多，对于用户来说看到的就是帖子标题列表页面，而标题列表页面最主要的信息都来自group_message表中，同时帖子的标题下面一般都是用户名来展示的。
2. 从表结构内容来看，帖子内容通常来说是很大的。在字段这块的设计我们可能就需要设置为text 同时最好是需要把text字段单独创建一个表存放
3. 系统对于用户的操作来说实际上最常获取的就是用户的id，昵称，密码，状态，邮箱，手机号码这些基础数据，相对来说其他数据是多余的；对于一个表来说字段越多数据表就会越大所以也可以考虑做一步拆分。

违反三大范式 添加多余的一个字段 结构图：

select
  id,author,id,subject
from
  article
where
  user_id = ? (代表参数)

建议

1. 尽量不要有太多的字段
2. 简单就好
3. 不要有太多的关联
4. 尽量不要有可以 NULL ()

总结:

1. 根据范式去设计数据库
2. 根据项目功能用户操作的比例调节字段(分割)
3. 根据查询业务,选择对应冗余 ( show status )
4. 分离出字段较大字段
   

? 作业 可不可以多次查询优化查询效率

可以执行两个查询，一个查用户表，一个查文章表 做一个数据处理

这个问题没有绝对的正确，相应的来说是需要开发者根据业务的需求分析即可。对于过于复杂的SQL就比较适合于