5 数据库
- 5.1 数据库命名规范
- 5.2 数据库字段命名
- - 5.2.1 字段命名规范
  - 5.2.2 命名规范
  - 5.2.3 待优化命名示例
  - 5.2.4 字段类型规范
  - 5.2.5数据库中每个字段的规范描述
- 5.3表设计
- 5.4 参考设计
- - 5.4.1 应用场景
  - 5.4.2 需求分析
  - 5.4.3 设计思路
  - 5.4.4 表结构设计
  - 5.4.5 缓存策略
  - Q1 冗余设计和一致性问题
  - Q2 为什么设计外键
- 总结
参考

5 数据库

5.1 数据库命名规范

采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线’‘组成，命名简洁明确，多个单词用下划线’'分隔,一个项目一个数据库，多个项目慎用同一个数据库
全部小写命名，禁止出现大写
禁止使用数据库关键字，如：name，time ，datetime，password等
表名称不应该取得太长（一般不超过三个英文单词）
表的名称一般使用名词或者动宾短语
用单数形式表示名称，例如，使用 employee，而不是 employees
表必须填写描述信息（使用SQL语句建表时）
数据库创建字符集：utf8mb4、排序规则：utf8mb4_general_ci

示例：档案管理数据库就是 bip_archives 表名就 archives_xxx

5.2 数据库字段命名

5.2.1 字段命名规范

采用26个英文字母(区分大小写)和0-9的自然数(经常不需要)加上下划线’‘组成，命名简洁明确，多个单词用下划线’'分隔
全部小写命名，禁止出现大写
字段必须填写描述信息
禁止使用数据库关键字，如：name，time ，datetime password 等
字段名称一般采用名词或动宾短语
采用字段的名称必须是易于理解，一般不超过三个英文单词
在命名表的列时，不要重复表的名称。例如，在名employe的表中避免使用名为employee_lastname的字段
不要在列的名称中包含数据类型
字段命名使用完整名称，禁止缩写
表中字段是另外一张表的主键，则为表名+id ，体现关联关系示例：user_id

5.2.2 命名规范

名词示例：user_id user_name sex
动宾短语示例：is_friend is_good

5.2.3 待优化命名示例

大小写规则不统一
错误示例：user_id houseID
说明：使用统一规则，修改为”user_id”，”house_id”

加下划线规则不统一
错误示例：username userid isfriend isgood
说明：使用下划线进行分类，提升可性，方便管理，修改为”user_name”，”user_id”，”is_friend”，”is_good”

字段表示不明确
错误示例：uid pid
说明：使用完整名称，提高可读性，修改为”user_id”，”person_id”

5.2.4 字段类型规范

所有字段在设计时，除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外，必须有默认值，字符型的默认值为一个空字符值串’’，数值型的默认值为数值0，逻辑型的默认值为数值0
系统中所有逻辑型中数值0表示为“假”，数值1表示为“真”，datetime、smalldatetime类型的字段没有默认值，必须为NULL
用尽量少的存储空间来存储一个字段的数据

使用int就不要使用varchar、char，

用varchar(16)就不要使varchar(256)

IP地址使用int类型

固定长度的类型最好使用char，例如：邮编(postcode)

能使用tinyint就不要使用smallint，int

最好给每个字段一个默认值，最好不能为null

字符转化为数字(能转化的最好转化，同样节约空间、提高查询性能)
避免使用NULL字段(NULL字段很难查询优化、NULL字段的索引需要额外空间、NULL字段的复合索引无效)
少用text类型(尽量使用varchar代替text字段)

5.2.5数据库中每个字段的规范描述

尽量遵守第三范式的标准（3NF）

表内的每一个值只能被表达一次
表内的每一行都应当被唯一的标示
表内不应该存储依赖于其他键的非键信息

如果字段事实上是与其它表的关键字相关联而未设计为外键引用，需建索引，大数据需要分库分表除外
如果字段与其它表的字段相关联，需建索引
如果字段需做模糊查询之外的条件查询，需建索引
除了主关键字允许建立簇索引外，其它字段所建索引必须为非簇索引

5.3表设计

表必须定义主键，默认为ID，整型自增，如果不采用默认设计必须咨询DBA进行设计评估。
ID字段作为自增主键。一般所有表都要有id, id必为主键，类型为bigint unsigned，单表时自增、步长为1。一般情况下主键id和业务没关系的。
强烈建议不使用外键, 数据的完整性靠程序来保证。
多表中的相同列，必须保证列定义一致。
使用InnoDB，字符集：utf8mb4、排序规则：utf8mb4_general_ci。
一般情况下每张表都有着五个字段，追踪数据的来源和修改，并且只能逻辑删除，不能物理删除，重要！
单表一到两年内数据量超过500w或数据容量超过10G考虑分表，且需要提前考虑历史数据迁移或应用自行删除历史数据。
单条记录大小禁止超过8k，一方面字段不要太多，有的都能上百，甚至几百个，另一方面字段的内容不易过大，像文章内容等这种超长内容的需要单独存到另一张表。
日志类数据不建议存储在MySQL上，优先考虑Hbase或OB，如需要存储请找DBA评估使用压缩表存储。
为了提高查询效率，可以适当的数据冗余，注意是适当。
字符串为主键很难做查询优化
禁止使用float、double类型，建议使用decimal或者int替代。
禁止使用blob、text类型保留大文本、文件、图片，建议使用其他方式存储，MySQL只保存指针信息。
————————————————
版权声明：本文为CSDN博主「码农书生」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/lijinzhou2017/article/details/108533932

5.4 参考设计

5.4.1 应用场景

实现功能：根据，综合，类型，地区，年份，演员等多级筛选。
一部电影对应多个类型
在这里插入图片描述

在这里插入图片描述

如上图所示，红框中的视频筛选标签，应该怎么设计数据库表结构?除了前台筛选，还想支持在管理后台灵活配置这些筛选标签。

实体类表：
类型表、地区表、年份表、演员表、片名表

关系类表：
片名表对应实体类关系表：

5.4.2 需求分析

1 可以根据红框的标签筛选视频

2 其中综合标签比较特殊，和类型、地区、年份、演员等不一样

综合是根据业务逻辑取值，并不需要入库
类型、地区、年份、演员等需要入库

3 设计表结构时要考虑到

方便获取标签信息，方便把标签信息缓存处理方便
根据标签筛选视频，方便我们写后续的业务逻辑

5.4.3 设计思路

1.综合标签(最热,好评，最新，即将上线)可以写到配置文件中 (威者写在前端)，这些信息不需要灵活配置，所以不需要保存到数据库中
2.类型、地区、年份、演员都设计单独的表
3.视频表中设计标签表的外键，方便视频列表筛选取值
4.标签信息写入缓存，提高接口响应速度
5.类型、地区、年份、演员表也要支持对数据排序，方便后期管理维护

5.4.4 表结构设计

视频表
在这里插入图片描述

其他和视频直接相关的字段（比如名称）省略不写

类型表
在这里插入图片描述
sort用来决定类型排序顺序，

年份表
在这里插入图片描述
年份表有一个10年代，所以需要排序字段灵活配置
演员表

表结构设计完了，还需要考虑缓存

5.4.5 缓存策略

首先这些不会频繁更新的筛选条件建议使用缓存

在这里插入图片描述
1.比较常用的就是redis缓存。

2.再进阶一点，如果你使用docker，可以把这些配置信息写入docker容器所在物理机的内存中，而不用请求其他节点的redis，进一步降低网络传输带来的耗时损耗。

3.筛选条件这类配置信息，客户端和服务端可以约定一个更新缓存的机制，客户端直接缓存配置信息，进一步提高性能。

列表数据自动缓存
很多框架都是支持自动缓存处理的，比如goframe和go-zero

Q1 冗余设计和一致性问题

提问:

一个表里做了这么多外键，如果我要查各自的名称，势必要关联4张表，对于这种存在多外键关联的这种表，要不要做几余呢(直接在主表里几余各自的名称字段)?
要是保证一致性的话，就势必会影响性能，如果做几余的话，又无法保证一致

回答：

目前我们解决的是视频列表筛选问题。你提到的这个场景是在视频详情信息中，如果要展示这些外键的名称怎么设计更好我的建议是这样的:

1.根据需求可以做适当几余，比如你的主表信息量不大（百万级别以下），配置信息修改后同步修改冗余字段的成本并不高。

2.或者像我文章中写的不做几余设计，但是会把外键信息缓存，业务查询从缓存中取值。 3或者将视频详情的查询结果整体进行缓存

还是看具体需求，如果这些筛选信息不变化或者不需要手工管理，甚至不需要设计表，直接写死在代码的配置文件中也可以。进一步降低DB压力，提高性能