命名规范：

https://blog.csdn.net/qq_30242987/article/details/94616841

一、数据库命名规范

采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线’_’组成，命名简洁明确，多个单词用下划线’_’分隔，一个项目一个数据库，多个项目慎用同一个数据库

二、数据库表命名规范

image.png

三、字段命名规范

image.png

四、字段类型使用规范

  1. （1）所有字段在设计时，除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外，必须有默认值，字符型的默认值为一个空字符值串’’，数值型的默认值为数值0，逻辑型的默认值为数值0
  3. （2）系统中所有逻辑型中数值0表示为“假”，数值1表示为“真”，datetime、smalldatetime类型的字段没有默认值，必须为NULL
  5. （3）用尽量少的存储空间来存储一个字段的数据
  7. 使用int就不要使用varchar、char，
  9. 用varchar(16)就不要使varchar(256)
  11. IP地址使用int类型
  13. 固定长度的类型最好使用char，例如：邮编(postcode)
  15. 能使用tinyint就不要使用smallint，int
  17. 最好给每个字段一个默认值，最好不能为null
  19. （4）用合适的字段类型节约空间
  21. 字符转化为数字(能转化的最好转化，同样节约空间、提高查询性能)
  23. 避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引无效)
  25. 少用text类型(尽量使用varchar代替text字段)

SQL：

DDL：

DML：

DCL

字段类型

image.png

bit：

类似布尔（？），占据硬盘空间。占1位，0/1，false或true等两种情况的布尔值。

Bit称为位数据类型，其数据有两种取值：0和1，长度为1位。在输入0以外的其他值时，系统均把它们当1看待。这种数据类型常作为逻辑变量使用，用来表示真、假或是、否等二值选择。

int：

数字，占32位，整数

decimal(M, N)：

数字，能精确计算的实数，M是总的数字位数，N是小数位数。计算过程比较慢。
比如：3.14159，M就是6（总共6位数字），N就是5（小数点后5位），超出截断。

其他小数：

double：64位的双精度小数。与JS中的小数类似
float：与double一样计算数据不够精确。

char(n)：

定长字符串，固定长度为n的字符。如果长度超出截断（？）、长度不够则自动空格补充。

varchar(n)：

不定长字符串，长度可变。最大长度为n的字符，超出n的限制存不下（会报错还是直接截断？）

text：

大量的字符，一般存取文本内容。其实还可以细分，自己了解

date：

仅日期（年月），无时间

datetime：

日期和时间，年月日时分秒都有

time

仅时间，无年月

主键和外键

主键：

每一张表里都需要有一个主键（当然可以没有），表示这个表中每一条数据的唯一标记。就好像每个学生的学生号、每个人的身份证号、每一条数据的ID一样。他必须保证是唯一不重复的。作用也就是让两条一模一样的数据也能被区分开。

主键特征：

主键必须唯一、决不能更改、不和业务逻辑挂钩

其实在表中改主键，当然也是可以的。但只是约定俗成的规范，约定不去更改这个主键。所以最好不要改。
只增不减，不能复用。

主键不能改的原因：

1、主键的存储方式比较特殊。他会建立一个索引，方便用主键查找数据的时候，加快速度。
2、当把一个字段设置为主键的时候，可能会在系统里边以这个主键为标准来设计。（比如，主键会因为唯一标识被当做查询字段，拿这个唯一id查找对应数据。如果主键修改了，那么查询信息就错乱了。）

允许用多列的组合当做主键（不常用）。如下图
image.png

主键类型：

可以是数字、也可以是字符串varchar，也可以是uuid。只不过通常用数字，为了自增。
如果是公司的业务，可能直接使用员工工号就行了。

uuid：

一个特别长的字符串，通过一定的算法计算出来的唯一标识。长度固定，能够保证全球唯一。

  1. SELECT UUID();

image.png

外键

产生表关系的列，用于将当前表和其他表进行关联。
关系型数据库就是设计好多张表。多个表之间的数据需要一一挂钩的话，就需要外键来关联。
一个表中可以有0到多个外键。但必须有一个主键。
比如：
一张班级表，一张学生表。班级表和学生表要挂钩的话，就要记录哪个学生属于哪个班级。
我们不能在学生表加一列写上哪个班级。而是应该加一个外键，关联班级表里的对应班级主键ID。
这样班级表里班级名字和其他信息修改，不影响学生表。学生表里，学生班级信息修改(转班）时，只需要修改外键就行，不影响班级。
这样，在学生表里，班级主键ID就是学生表里的外键。
再比如，在公司的员工表里，员工编号就是主键。但是在其他业务表里，记录员工操作信息的时候，erp就成了操作记录表的外键。

学生表中添加用于外键的字段：

image.png

学生表中关联外键：

image.png

表关系查看：

🔑表示主键
◇表示外键
image.png

表关系

一对一【少见】

一个A对应一个B，一个B对应一个A。**这两句话要同时满足。
比如：用户表和用户信息表，就是一对一关系。
一对一关系表不常见，因为通常这种数据需求都可以建立在同一张表中。不需要建多张表来维护表关系。
但是如果业务复杂、数据量庞大时，一个表通常会被拆分开两个表，这样两个表之间就会出现一对一的关系。
处理方案：这种情况，说白了，就是两张表通用一个id。**
所以在每个表中，同一个外键id只对应一条数据。多条数据之前不能共用一个外键id了。因为这样就不是一对一关系了。
image.png
操作原理是，将id拖拽到login表的userid上，id就成了info的外键，关联的是login表的userid主键。
image.png
修改后保存、刷新就能看到关联关系

表现特征

就是把任意一张表的主键同时设置为外键。
image.png

一对多【常见】

一个A对应多个B，一个B对应一个A，A和B是一对多，B和A是多对一。
例如：班级和学生，用户和文章。
处理方案：再「多」一端的表上设置外键，对应到另一张表的主键。
上边外键那里的学生表和班级表的举例就是这个关系。

多对多

一个A对应多个B，一个B对应多个A。
例如：学生和老师，用户购物车和商品
处理方案：需要新建一张关系表，关系表至少包含两个外键，分别对应到两张表。
如下：

关系表

表中有一个主键，多个外键。不同外键关联其他不同表的id，通过这个关系表，把其他多个不同表关联起来。
用于处理多对多关系。
image.png

关系表ER视图

下图中，buy_relation就是关系表。两个外键user_id和products_id分别关联购物车表和产品表。
image.png

三大设计范式

  1. 列不可分：要求数据库的每一列都是不可分割的原子数据项
  2. 非主键列必须要依赖主键列。每一列都必须和主键有关系，比如依赖学生主键id里有一列为「校长」，这就没关系了
  3. 非主键列必须直接依赖主键列。每一列都是直接依赖主键的，比如依赖学生主键id里有一列为「班级名称」，那这一列其实应该是班级信息，依赖班级主键id的。而学生表里应该填班级id而不是班级名称的。

其他：
尽量避免数据冗余
好处：方便读取。比如两个列“出生日期”和“年龄”就是冗余。但好处是可以单独获取不用计算了。
坏处：不利于写。比如我修改了出生日期，还要修改年龄

问题

1、增加了一个字段，然后之前设计了一半的表内部没有这个字段，并且保存的时候报错
image.png
2、bit类型的字段，长度为1，为啥sex这里还是0000001？

以上两个问题

在我关掉没保存的设计面板和表数据面板后，左边菜单栏刷新表，然后重新打开。两个问题都解决了。可能就是之前改了没保存或者没运行、没刷新吧。