初学后端,如何做好表结构设计?
前言
最近有不少前端和测试转Go的朋友在交流群里聊:如何做好表结构设计?
大家关心的问题阳哥必须整理出来,希望对大家有帮助。
先说结论
这篇文章介绍了设计数据库表结构应该考虑的4个方面,还有优雅设计的6个原则,举了一个例子分享了我的设计思路,为了提高性能我们也要从多方面考虑缓存问题。
收获最大的还是和大家的交流讨论,总结一下:
- 首先,一定要先搞清楚业务需求。比如我的例子中,如果不需要灵活设置,完全可以写到配置文件中,并不需要单独设计外键。主表中直接保存各种筛选标签名称(注意维护的问题,要考虑到数据一致性)
- 数据库表结构设计一定考虑数据量和并发量,我的例子中如果数据量小,可以适当做冗余设计,降低业务复杂度。
4个方面
设计数据库表结构需要考虑到以下4个方面:
数据库范式:通常情况下,我们希望表的数据符合某种范式,这可以保证数据的完整性和一致性。例如,第一范式要求表的每个属性都是原子性的,第二范式要求每个非主键属性完全依赖于主键,第三范式要求每个非主键属性不依赖于其他非主键属性。
实体关系模型(ER模型):我们需要先根据实际情况画出实体关系模型,然后再将其转化为数据库表结构。实体关系模型通常包括实体、属性、关系等要素,我们需要将它们转化为表的形式。
数据库性能:我们需要考虑到数据库的性能问题,包括表的大小、索引的使用、查询语句的优化等。
数据库安全:我们需要考虑到数据库的安全问题,包括表的权限、用户角色的设置等。
设计原则
在设计数据库表结构时,可以参考以下几个优雅的设计原则:
简单明了:表结构应该简单明了,避免过度复杂化。
一致性:表结构应该保持一致性,例如命名规范、数据类型等。
规范化:尽可能将表规范化,避免数据冗余和不一致性。
性能:表结构应该考虑到性能问题,例如使用适当的索引、避免全表扫描等。
安全:表结构应该考虑到安全问题,例如合理设置权限、避免SQL注入等。
扩展性:表结构应该具有一定的扩展性,例如预留字段、可扩展的关系等。
最后,需要提醒的是,优雅的数据库表结构需要在实践中不断迭代和优化,不断满足实际需求和新的挑战。
下面举个示例让大家更好的理解如何设计表结构,如何引入内存,有哪些优化思路:
问题描述
如上图所示,红框中的视频筛选标签,应该怎么设计数据库表结构?除了前台筛选,还想支持在管理后台灵活配置这些筛选标签。
这是一个很好的应用场景,大家可以先自己想一下。不要着急看我的方案。
需求分析
- 可以根据红框的标签筛选视频
- 其中综合标签比较特殊,和类型、地区、年份、演员等不一样
- 综合是根据业务逻辑取值,并不需要入库
- 类型、地区、年份、演员等需要入库
- 设计表结构时要考虑到:
- 方便获取标签信息,方便把标签信息缓存处理
- 方便根据标签筛选视频,方便我们写后续的业务逻辑
设计思路
- 综合标签可以写到配置文件中(或者写在前端),这些信息不需要灵活配置,所以不需要保存到数据库中
- 类型、地区、年份、演员都设计单独的表
- 视频表中设计标签表的外键,方便视频列表筛选取值
- 标签信息写入缓存,提高接口响应速度
- 类型、地区、年份、演员表也要支持对数据排序,方便后期管理维护
表结构设计
视频表
字段 | 注释 |
---|---|
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 | 排序字段 |
表结构设计完了,别忘了缓存
缓存策略
首先这些不会频繁更新的筛选条件建议使用缓存:
- 比较常用的就是redis缓存
- 再进阶一点,如果你使用docker,可以把这些配置信息写入docker容器所在物理机的内存中,而不用请求其他节点的redis,进一步降低网络传输带来的耗时损耗
- 筛选条件这类配置信息,客户端和服务端可以约定一个更新缓存的机制,客户端直接缓存配置信息,进一步提高性能
列表数据自动缓存
目前很多框架都是支持自动缓存处理的,比如goframe和go-zero
goframe
可以使用ORM链式操作-查询缓存
示例代码:
package mainimport ("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())// 开启调试模式,以便于记录所有执行的SQLdb.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设计外键?
提问:为什么要设计外键关联?直接写到视频表中不就行了?这么设计的意义在哪里?
回答:
- 关键问题是想解决管理后台灵活配置
- 如果没有这个需求,我们可以直接把筛选条件以配置文件的方式写死在程序中,降低复杂度。
- 站在我的角度:这个功能的筛选条件变化并不会很大,所以很懂你的意思。也建议像我2.中的方案去做,去和产品经理拉扯喽~
总结
这篇文章介绍了设计数据库表结构应该考虑的4个方面,还有优雅设计的6个原则,举了一个例子分享了我的设计思路,为了提高性能我们也要从多方面考虑缓存问题。
收获最大的还是和大家的交流讨论,总结一下:
- 首先,一定要先搞清楚业务需求。比如我的例子中,如果不需要灵活设置,完全可以写到配置文件中,并不需要单独设计外键。主表中直接保存各种筛选标签名称(注意维护的问题,要考虑到数据一致性)
- 数据库表结构设计一定考虑数据量和并发量,我的例子中如果数据量小,可以适当做冗余设计,降低业务复杂度
本文抛砖引玉,欢迎大家留言交流。
文章首发
我的文章会首发在我的公众号:程序员升职加薪之旅,欢迎大家关注,第一时间收到最新内容。
一起学习
我的所有文章都会首发在我的 学习小圈子 ,欢迎加入我们,一起学习进步,一起升职加薪。
初学后端,如何做好表结构设计?相关推荐
- Shiro表结构设计
表设计 开发用户-角色-权限管理系统,首先我们需要知道用户-角色-权限管理系统的表结构设计. 在用户-角色-权限管理系统找那个一般会涉及5张表,分别为: 1.sys_users用户表 2.sys_ro ...
- 分布式列数据库--理解hbase列存储机制、架构、表结构设计、命令操作
1. HBase简介 HBase是Hadoop Database的简称,是建立在Hadoop文件系统之上的分布式面向列的数据库. HBase和HDFS HDFS适用于存储大容量文件的分布式文件系统,不 ...
- BBS(仿博客园系统)项目01(项目分析、表结构设计、注册功能实现)
摘要: 需求分析 表结构设计 注册功能实现 一.需求分析: 项目需求(产品经理.架构师.开发组组长与客户谈该项目相关要求) 项目设计 (架构师需要思考:框架选择,数据库选择,主要功能模块,报价:包括工 ...
- MySQL表结构设计
MySQL表结构设计包括:字段类型选择 + 物理存储设计 + 表的访问设计. 数字类型 整型类型 在整型类型中,有 signed 和 unsigned 属性,其表示的是整型的取值范围,默认为 sign ...
- 数据库表结构设计原则
转载自:http://hi.baidu.com/yzx110/blog/item/0159fadc7b7839a4cd116686.html 数据库表结构设计浅谈 这篇文章如题所述,只打算谈一下数据库 ...
- 用户数据表设计借鉴 浅谈数据库用户表结构设计,第三方登录 基于 Token 的身份验证
最近对用户数据表的设计比较感兴趣,看到了两篇比较好的文章. 浅谈数据库用户表结构设计,第三方登录 转载于: https://www.cnblogs.com/jiqing9006/p/5937733.h ...
- mysql 数据库表结构设计与规范
mysql 数据库表结构设计与规范 DDL(data difinition language)就是数据定义语言. 1.sql语句的界定符 [code]– 默认情况下" ; " 代表 ...
- 数据库架构设计——表结构设计
摘要 如何打造出一个能支撑海量的并发访问的分布式 MySQL 架构,本系列博文将从一下多个方面来分析有关MYSQL系统的架构设计相关原理.实际的业务为案例分析,分析实际业务中表使用的字段类型是如何选型 ...
- HBase表结构设计(结构、创建、压缩、分区、命名空间等)
HBase表结构设计(结构.创建.分区.命名空间等) 任务表述: 如果用户点击某一行数据则触发接口写数据进入HBase.那么当用户再次读取数据的时候数据A和数据B返回的数据就需要给返回的数据另外增加一 ...
最新文章
- supervisor 管理进程
- ubuntu12.04安装libgl1-mesa-glx:i386问题解决办法
- nosuchelementexception 是什么异常_有甲状腺结节的人为什么越来越多?
- java windows wrapper_Java Service Wrapper 发布windows后台程序的方法
- 【算法导论】第7章快速排序
- Python 操作 Windows 粘贴板
- svn 配置详解,以及各种可能遇到的问题
- [转]Vs解决方案的目录结构设置和管理
- 「leetcode」454.四数相加II:其实需要哈希的地方都能找到map的身影
- 怎样用一个鼠标和键盘控制两台电脑
- c语言编写比赛评分程序,比赛评分系统c语言课程设计.doc
- mySQL字段中斜杠_MySQL 列名中包含斜杠或者空格的处理方法
- OracleRAC基本概念及入门
- flutter doctor --android-licenses后Android sdkmanager not found.
- java系列之:获取当前时间和当前时间上一个小时的时间
- 将Shapefile数据导入Winbugs的方法
- 王者荣耀是用什么软件和编程语言开发的
- python使用163邮箱发送邮件
- 基于ISA/TMG的双线接入
- POI-5.2.2 操作Word【单元格、行、列】