不少前端和测试转Go的朋友私信我：如何做好表结构设计？
大家关心的问题阳哥必须整理出来，希望对大家有帮助。
先说结论
这篇文章介绍了设计数据库表结构应该考虑的4个方面，还有优雅设计的6个原则，举了一个例子分享了我的设计思路，为了提高性能我们也要从多方面考虑缓存问题。
收获最大的还是和大家的交流讨论，总结一下：
4个方面
设计数据库表结构需要考虑到以下4个方面：
设计原则
在设计数据库表结构时，可以参考以下几个优雅的设计原则：
最后，需要提醒的是，优雅的数据库表结构需要在实践中不断迭代和优化，不断满足实际需求和新的挑战。
下面举个示例让大家更好的理解如何设计表结构，如何引入内存，有哪些优化思路：
问题描述
如上图所示，红框中的视频筛选标签，应该怎么设计数据库表结构？除了前台筛选，还想支持在管理后台灵活配置这些筛选标签。
这是一个很好的应用场景，大家可以先自己想一下。不要着急看我的方案。
需求分析
设计思路
表结构设计
视频表
| 字段 | 注释 |
|---|---|
| id | 视频主键id |
| type_id | 类型表外键id |
| area_id | 地区表外键id |
| year_id | 年份外键id |
| actor_id | 演员外键id |
其他和视频直接相关的字段（比如名称）我就省略不写了
类型表
| 字段 | 注释 |
|---|---|
| id | 类型主键id |
| name | 类型名称 |
| sort | 排序字段 |
地区表
| 字段 | 注释 |
|---|---|
| id | 类型主键id |
| name | 类型名称 |
| sort | 排序字段 |
年份表
| 字段 | 注释 |
|---|---|
| id | 类型主键id |
| name | 类型名称 |
| sort | 排序字段 |
原以为年份字段不需要排序，要么是年份正序排列，要么是年份倒序排列，所以不需要sort字段。
仔细看了看需求，还有“10年代”还是需要灵活配置的呀~
演员表
| 字段 | 注释 |
|---|---|
| id | 类型主键id |
| name | 类型名称 |
| sort | 排序字段 |
表结构设计完了，别忘了缓存
缓存策略
首先这些不会频繁更新的筛选条件建议使用缓存：
列表数据自动缓存
目前很多框架都是支持自动缓存处理的，比如goframe和go-zero
goframe
可以使用ORM链式操作-查询缓存
示例代码：
package main
import (
"time"
"github.com/gogf/gf/v2/database/gdb"
"github.com/gogf/gf/v2/frame/g"
"github.com/gogf/gf/v2/os/gctx"
)
func main() {
var (
db = g.DB()
ctx = gctx.New()
)
// 开启调试模式，以便于记录所有执行的SQL
db.SetDebug(true)
// 写入测试数据
_, err := g.Model("user").Ctx(ctx).Data(g.Map{
"name": "xxx",
"site": "https://xxx.org",
}).Insert()
// 执行2次查询并将查询结果缓存1小时，并可执行缓存名称(可选)
for i := 0; i < 2; i++ {
r, _ := g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{
Duration: time.Hour,
Name: "vip-user",
Force: false,
}).Where("uid", 1).One()
g.Log().Debug(ctx, r.Map())
}
// 执行更新操作，并清理指定名称的查询缓存
_, err = g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{
Duration: -1,
Name: "vip-user",
Force: false,
}).Data(gdb.Map{"name": "smith"}).Where("uid", 1).Update()
if err != nil {
g.Log().Fatal(ctx, err)
}
// 再次执行查询，启用查询缓存特性
r, _ := g.Model("user").Ctx(ctx).Cache(gdb.CacheOption{
Duration: time.Hour,
Name: "vip-user",
Force: false,
}).Where("uid", 1).One()
g.Log().Debug(ctx, r.Map())
}
go-zero
DB缓存机制
go-zero缓存设计之持久层缓存
官方都做了详细的介绍，不作为本文的重点。
讨论
这篇文章首发在我的公众号《如何做好表结构设计？》，引起了大家的讨论。
也和大家分享一下：
Q1 冗余设计和一致性问题
提问： 一个表里做了这么多外键，如果我要查各自的名称，势必要关联4张表，对于这种存在多外键关联的这种表，要不要做冗余呢(直接在主表里冗余各自的名称字段)？要是保证一致性的话，就势必会影响性能，如果做冗余的话，又无法保证一致性
回答：
你看文章的上下文应该知道，文章想解决的是视频列表筛选问题。
你提到的这个场景是在视频详情信息中，如果要展示这些外键的名称怎么设计更好。
我的建议是这样的：
还是看具体需求，如果这些筛选信息不变化或者不需要手工管理，甚至不需要设计表，直接写死在代码的配置文件中也可以。进一步降低DB压力，提高性能。
Q2 why设计外键？
提问：为什么要设计外键关联？直接写到视频表中不就行了？这么设计的意义在哪里？
回答：
总结
这篇文章介绍了设计数据库表结构应该考虑的4个方面，还有优雅设计的6个原则，举了一个例子分享了我的设计思路，为了提高性能我们也要从多方面考虑缓存问题。
收获最大的还是和大家的交流讨论，总结一下：
