转用Go开发：如何设计数据库表结构？

前面很多转Go测试的朋友私信我：如何设计好表结构？

阳哥需要解决大家关心的问题。我希望它对每个人都有用。

先说结论

本文介绍了设计数据库表结构时需要考虑的4个方面，以及优雅设计的6个原则。它提供了示例来展示我的设计思想。为了提高性能，我们还必须从多方面考虑Caching问题。

最有用的就是和大家交流讨论。总结一下：

1. 首先，您需要了解您的业务需求。例如示例中，如果不需要灵活设置，可以写入配置文件，不需要单独设计外键。将各种过滤标签名直接存储在主表中（考虑维护问题，考虑数据一致性）
2. 数据库表结构的设计要考虑数据量和并发量。在我的例子中，如果数据量很小，可以精确地进行冗余设计，降低业务的复杂度。

4 个方面

在设计数据库表结构时，应该考虑以下 4 个方面：

1. 数据库范式 ：通常情况下，我们希望表中的数据是合适的，与表中的数据一致。范式确定。可以保证数据类型的完整性和一致性。例如，第一范式要求表的每个属性都是原子的，第二范式要求每个非主键属性完全依赖于主键，第三范式要求每个非主键属性独立于主键。任何其他非主键属性。
2. 实体关系模型（ER模型）：我们需要根据实际情况先绘制实体关系模型，然后将其转换为数据库表结构。实体关系模型通常包括实体、属性、关系等元素，我们需要将它们转换成表格形式。
3. 数据库性能：我们需要考虑数据库性能问题，包括表大小、索引使用情况、查询语句优化等。表权限、用户角色设置等

设计原则

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

1. 简单明了应该简单：表结构应该简单：明晰，避免过度-并发症。
2. 一致性：表结构必须保持一致性，例如命名约定、数据类型等。
3. 性能：表结构应考虑性能问题，例如使用适当的索引、避免全表扫描等。适当的权限，避免SQL注入等。
4. 可扩展性：表结构必须具有一定的可扩展性，例如受保护的列、可扩展的关系等。不断满足现实需求和新挑战。

   下面举个例子，让大家更好的理解如何设计表结构，如何引入内存，有哪些优化思路：视频中红框里的这样？数据库表结构设计？ 除了前端过滤之外，我们还希望支持在管理后端灵活配置这些过滤标签。

   这是一个很好的应用场景，你可以先自己思考一下。别急着看我的计划。

   需求分析

   1. 可以根据红框内的标签过滤视频
   2. 全标签是自定义的，根据性别、地区、年份、演员等不同
   3. 全标签以Values为基础基于业务逻辑，无需存储
   4. 类型、地区、年份、演员等。必须存储在数据库中
   5. 设计表结构时考虑：
   6. 方便标记信息和缓存标记信息
   7. 方便根据标签过滤视频。方便我们后面写业务逻辑

   设计思想

   1. 完整的标签可以写在配置文件中（或者写在前端）。这些信息不需要灵活配置，所以不需要存储在数据库中
   2. 类型、地区、年份、演员分别设计了单独的表
   3. 标签表中的外键设计在视频表，方便过滤视频列表
   4. 缓存中写入标签信息，提高界面的响应速度
   5. 流派、地区、年份、播放器列表还应该支持排序数据，方便后期管理和维护

   表结构设计

   视频表

   字段	评论
   id	视频主键ID‶type_asing键id
   id_area	外键id地区表
   id_year	id 外键年份
   actor_id	id 外键演员

   与视频直接相关的其他字段（如姓名）表

   字段	评论
   id	类型主键id
   名称	名称类型排序
   区域表 box note id 类型主键id 名称 输入名称 sort 表排序列♶♶ 备注 id 键入主键id 名称 类型名称 sort 对列进行排序 I本来以为年份列不需要排序，或者说年份按年份倒序排序，所以不需要列排序。 仔细看需求，“10秒”还是需要灵活配置的~ 演员表 字段 评论♿♝id♿id姓名 输入姓名 排序 对列进行排序 表结构设计好后，不要忘记缓存 缓存策略 对于不会经常更新的内容建议使用此过滤器： 比较最常用的是redis缓存 再进一步，如果使用docker的话，可以将这个配置信息写入docker容器所在物理机的内存中。定位，无需向其他节点请求redis，进一步减少网络传输带来的消耗。时间损失 对配置信息进行条件过滤，客户端和服务端可以约定更新缓存的机制，客户端立即保存配置信息，提高性能 列表数据自动缓存 很多目前的框架都支持自动缓存处理，比如Goframe和Go-Zero goframe 可以使用链式操作ORM -Cache持久层缓存设计零 官方已经详细介绍了，不是本文的重点。 讨论 本文首发于公众号《如何做好表结构设计？》，引起大家讨论。 还有你： Q1 冗余设计和一致性问题 问题：一张表有很多外键。如果我想查所有者的名字，就需要关联4个表。对于这种多外键关联的表，我们需要创建冗余（所有者姓名的字段直接在主表中冗余）？如果保证一致性，性能肯定会受到影响。如果使用冗余，则无法保证一致性。 你提到的场景在视频详情里。如果要显示这些外键名称，如何规划更好。 我的建议是这样的： 您可以根据您的需要创建适当的冗余。例如，如果你的主表信息很少，那么更改配置信息后同步更改冗余字段的成本并不高。 或者像我文章里写的那样，没有多余的设计，但是外键信息会被缓存，业务查询会从缓存中获取值。 或者将视频详情的查询结果整体缓存 还是要看你的具体需求了。如果过滤信息不发生变化或者不需要人工管理，甚至不需要设计表，可以直接写入代码配置文件中。 。进一步降低DB压力，提升性能。 Q2 为什么要设计外键？ 问题：为什么需要设计外键关系？直接写入视频表还不够吗？这样的设计有什么意义呢？ 答： 主要是解决管理后台的灵活配置问题 如果没有这个需求，我们可以直接将过滤条件以配置文件的形式写入程序中，以减少复杂。 从角度来看：这个函数filter的状态变化不大，所以我明白你的意思。也建议像2.中的解决方案一样做，和产品经理谈谈~ 总结 本文介绍了设计数据库表结构时需要考虑的4个方面，以及6个优雅原则。设计方面，我举个例子来展示设计思路。为了提高性能，我们还需要从多方面考虑缓存问题。 最有用的就是和大家交流讨论。总结一下： 首先，您需要了解您的业务需求。例如示例中，如果不需要灵活设置，可以写入配置文件，不需要单独设计外键。将各种过滤标签名直接存储在主表中（考虑维护问题，考虑数据一致性） 数据库表结构的设计要考虑数据量和并发量。以我的例子来说，数据量小的话，可以精确完成 冗余设计，降低业务复杂度