数据库基本概念
数据库语言
数据库主要运用SQL语言，SQL语言主要分为4个部分
将SQL语言分成4个部分主要是因为SQL语言纷繁复杂，定义4个种类的语言方便管理及记忆。
SQL语言主要面向这4个对象，数据库和数据表，数据表中的记录，数据库的连接权限及一些其他的属性，查询数据库中记录
DDL （data definition language）数据定义语言，用于定义数据库对象。
我们可以用DDL来建数据库，建表，定义表的字段，并修改和删除数据库和数据表的结构
DML （data manipulation language）数据操作语言
用来操作数据库中的记录
DCL （data control language）数据控制语言
我们用这个语言定义数据库的访问权限和安全级别
DQL （data query language）数据查询语言
如果说前面三种语言一般都用于我们数据库的构建，那么这种语言就是用于数据库的使用。
DQL语言能进行等值查询和区间查询，还能支持正则表达式
视图
视图技术的应用一般是下面这种场景。
你构建的数据库数据量比较大，但是你常用的数据表及表中的记录只有一部分，而你每次要查询数据库时都要访问整个表，这样就会导致效率比较低。
这个时候视图就发挥作用了。我们可以将我们常用的查询的记录封装成一个视图，之后要使用这些记录的时候从视图中查询就行了
下面是创建视图,删除视图的语句
(SQL语句一般让关键字字段大写，其余字段小写)
CREATE VIEW name AS
SELECT col1, col2,
FROM table
WHERE condition
DROP VIEW name
视图可以嵌套，也就是在视图上创建视图
对一些相似概念进行对比能增加对概念的理解，视图和临时表有些相像，也有一些区别
数据层面：视图是一个虚拟表，不存在实体数据。而临时表是存在实体数据的，所以我们一般不能通过视图对临时表进行修改。
当然，从这个概念看，其实看不出视图和临时表在使用上的区别，因为我们一般也不会去修改临时表的数据，下一个不同是一个使用上的区别
持续时间层面：视图是能够长久保存的，而临时表却只能存在于当前的连接。
键
数据库定义了一大堆的概念，在键这个层面上也是。
先说说常用的键的概念，主键和外键
主键是数据表中可以唯一标识一条记录的字段，每个数据表中只有一个。
这么说可能还会有一些疑惑，因为在一个数据表中可以唯一标识一个记录的字段可能不止一个，比如一个数据表中存在了一个用户ID，还存在了用户身份证号，这时这两个属性都可以用来标识这个用户，那么哪个是主键呢？
答案就是你选定的那个就是主键，在建表的过程中，有一个PRIMARY字段可以用来标识主键。
外键就是数据表中表示别的表的主键的字段。
比如有两个表，一个主人表和一个宠物表。
主人表中的主键为标识主人的ID，宠物表中主键为宠物ID，但是宠物表中也会有主人ID这个字段，用来标识宠物的主人是谁，这时，对于宠物表来说，主人ID字段就是它的外键。
构建外键一般是为了实现外键约束，保证表的关联性。
除了这两个常用到的概念外，我们还有超键，候选键等概念
超键为能唯一标识元组的属性集，
候选键为能唯一标识元组的属性集的最小集
很抽象，举个例子就很好理解
加入一个表的字段有
ID 姓名 生日 身份证号
超键就是包含ID或身份证号的属性集合，比如（ID 姓名）（生日 身份证号）等
候选键为ID或身份证号
约束
数据的采集过程是存在很多脏数据的，在建表的过程中要维护数据库数据的正确性，一致性并不容易，如果每次都要人为检查的话会很麻烦，所以数据库增加了数据约束这一手段辅助我们管理好我们的数据。
数据库约束常见的有五种
唯一性约束
非空约束
自增约束
主键约束
外键约束
前面三种约束（唯一性约束，非空约束，自增约束）很好理解，从名字上就能看出来
唯一性约束使数据不能重复，非空约束保证数据不为null，自增约束保证数据是自动增长的。
主键约束为非空约束和唯一性约束的集合。
外键约束用于两表之间的联系，添加外键约束后，主表不能删除从表存在的数据，从表不能增加主表不存在的数据。这样就避免了误删操作
约束的添加方法
添加约束有几种情景，在建表的时候添加约束，在表建成之后添加约束
-- 建表时添加主键
CREATE TABLE name{
filed1 TYPE1 PRIMARY KEY,
filed2 TYPE2
};
-- 建表之后添加主键
ALTER TABLE name ADD PRIMARY KEY(filed1)
除了外键约束都可以这样实现
--添加外键约束
ALTER TABLE name1 ADD FOREIGN KEY(filed1) REFERENCES name2(filed2)
name1为存在外键的表的名称
name2为主表的名称
filed1和filed2为需要指定为外键的字段 一般filed1为外表的外键，filed2为主表的主键
增加外键后要删除或添加记录的话应该在主表和外表一起添加或删除
用删除来举例
删除一般有两种方法
第一种方法
--级联删除
ALTER TABLE name1 ADD FOREIGN KEY(filed1) REFERENCES name2(filed2) ON DELETE CASCADE
第二种方法
先删除从表中的数据，再删除主表中的数据
增加与此类似
范式
我们在构建数据表时，可能会有很多种建表的选择，那么怎样建表才比较好，方便以后的使用呢？
数据库的范式就是用来解决这个问题，它规定了数据表应该遵守的一些规范
关系型数据库一共有6个规范，从低到高分别为1NF，2Nf，3NF，4NF，BCNF，5NF。
设计范式越高阶，冗余就越低。我们主要使用的是前三个范式。
下面按照3个范式分别举例子
下面是这样一种场景，电商的配送系统中有这么一张表，其中有个地址字段，里面的值为省份、城市、县、街道。
这样设计是有很多冗余的，而且表不好用，比如我们只要查一个人所在的城市的时候，利用这张表只能先查出地址，然后从地址中解析出城市来。所以我们应该避免这样的设计
第一范式就是对这种情况的规范
1NF 指的是数据库表中的任何属性都是原子性的，不可再分
另一个场景
一张球员比赛表 player_game，里面包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性，这里候选键和主键都为由两个字段决定（球员编号，比赛编号）
（ps 该例子参考极客时间SQL必知必会）
但是这样设计有问题，一个球员可以参加多场比赛，那么这个球员的姓名和年龄就会被插入多次，这样就存在数据冗余。
在数据插入时，如果我们只知道比赛信息，还未确定球员情况，因为球员编号也是主键的一部分，所以我们无法进行插入
删除也会有异常，当我们要删除某个球员的时候，如果没有单独保存比赛信息，球员对应的比赛也会被删除
实际上遵守第二范式就能避免这种情况的发生。
2NF 指的数据表里的非主属性都要和这个数据表的候选键有完全依赖关系
完全依赖指的是若候选键由两个部分组成，不能只依赖候选键中的其中一个部分
而这个场景中，球员的姓名和年龄就只依赖于球员编号
比赛时间和比赛场地就只依赖于比赛编号，这显然是违反第二范式的
场景三
用球员 player 表举例子，这张表包含的属性包括球员编号、姓名、球队名称和球队主教练。
在这个场景中，球员编号决定了球队名称，同时球队名称决定了球队主教练，非主属性球队主教练就会传递依赖于球员编号。球队的主教练就会产生冗余，因为多个球员可能存在于同一个球队，在删除和插入时也容易出现前面场景中的异常。
第三范式就定义了这么一个场景。
3NF 在满足 2NF 的同时，对任何非主属性都不传递依赖于候选键
说到范式，那么范式一定好吗，一定能满足所有需求吗？不是这样的，所以出现了反范式设计。
下面有这么一个表，里面内容是关于一个商品的评论
还有另外一张表
假设我们要查看某商品的前100条评论及评论的用户昵称时，我们需要两表连接，还要排序，才能得到我们想要的内容。然而在比较数据量较大的场景下这样是非常耗时的，此时我们可以考虑将用户昵称加入到第一张商品评论表中，这样能提高查询的效率。
这就是反范式设计。
可以看出反范式设计是利用空间换时间的思路，在数据量小时这样不能提升性能优势，但数据量大时，如果某些冗余信息很有价值，能大幅度提高查询效率，就可以考虑使用反范式设计。