如何做好表结构设计？ _表结构

前言最近有不少前端和测试转Go的朋友在??交流群??里聊：如何做表结构设计？
大家关心的问题阳哥必须整理出来，希望对大家有帮助。
4个方面设计数据库表结构需要考虑到以下4个方面：

数据库范式：通常情况下，我们希望表的数据符合某种范式，这可以保证数据的完整性和一致性。例如，第一范式要求表的每个属性都是原子性的，第二范式要求每个非主键属性完全依赖于主键，第三范式要求每个非主键属性不依赖于其他非主键属性。
实体关系模型（ER模型）：我们需要先根据实际情况画出实体关系模型，然后再将其转化为数据库表结构。实体关系模型通常包括实体、属性、关系等要素，我们需要将它们转化为表的形式。
数据库性能：我们需要考虑到数据库的性能问题，包括表的大小、索引的使用、查询语句的优化等。
数据库安全：我们需要考虑到数据库的安全问题，包括表的权限、用户角色的设置等。

设计原则在设计数据库表结构时，可以参考以下几个优雅的设计原则：

简单明了：表结构应该简单明了，避免过度复杂化。
一致性：表结构应该保持一致性，例如命名规范、数据类型等。
规范化：尽可能将表规范化，避免数据冗余和不一致性。
性能：表结构应该考虑到性能问题，例如使用适当的索引、避免全表扫描等。
安全：表结构应该考虑到安全问题，例如合理设置权限、避免SQL注入等。
扩展性：表结构应该具有一定的扩展性，例如预留字段、可扩展的关系等。

最后，需要提醒的是，优雅的数据库表结构需要在实践中不断迭代和优化，不断满足实际需求和新的挑战。

下面举个示例让大家更好的理解如何设计表结构，如何引入内存，有哪些优化思路：

问题描述

文章插图

如上图所示，红框中的视频筛选标签，应该怎么设计数据库表结构？
这是一个很好的应用场景，大家可以先自己想一下。不要着急看我的方案。
需求分析

可以根据红框的标签筛选视频
其中综合标签比较特殊，和类型、地区、年份、演员等不一样

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

设计表结构时要考虑到：

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

设计思路

综合标签可以写到配置文件中（或者写在前端），这些信息不需要灵活配置，所以不需要保存到数据库中
类型、地区、年份、演员都设计单独的表
视频表中设计标签表的外键，方便视频列表筛选取值
标签信息写入缓存，提高接口响应速度
类型、地区、年份、演员表也要支持对数据排序，方便后期管理维护

表结构设计视频表字段
注释
id
视频主键id
type_id
类型表外键id
area_id
地区表外键id
year_id
年份外键id
actor_id
演员外键id
其他和视频直接相关的字段（比如名称）我就省略不写了
类型表字段
注释
id
类型主键id
name
类型名称
sort
排序字段