数据库基础(四)——数据库设计规范
前言
数据库设计一般来说是比较难的,虽然在看书或者学习过程中我们可以快速理解数据库设计的相关规范和概念,但是实际创建数据库的时候却很难下手。
在这方面只能说是天赋加经验,二者缺一不可,这就是很多程序员在IT方面一辈子只能是码农,而有些程序员在却能很快掌握技巧并有很好的发展。这个东西只能说是看命,天赋并不是真的与生俱来,很多人通过后天学习突然顿悟也有可能在这方面飞速发展。
说这些不是为了劝退各位,有些时候我们只能看命。但我依旧相信,努力终有回报,一起加油!
概述
-
糟糕的数据库设计:
- 数据冗余,浪费空间;
- 数据库插入和删除都会造成时间复杂度或空间复杂度提升,甚至产生异常等情况;
- 程序的性能差。
-
良好的数据设计:
- 节省内存空间;
- 保证数据库的完整性;
- 方便我们开发系统。
数据库设计
数据库设计步骤
- 分析需求:分析业务和需要处理的数据库的需求;
- 概要设计:设计关系统E-R图。
举个栗子
以个人博客为例:
-
收集信息、分析需求:
-
分析角色:
-
用户表:用户包括以下数据及功能
登录注册;
个人信息;
写博客;
创建分类(用户可以自己创建自己的分类);
-
分类表:分类表具有以下数据
文章分类;
分类创建者;
-
文章表:
文章的信息;
-
友情链接表:
友情链接信息;
-
管理员:
除了用户的基本信息及功能以外,还拥有管理权限;
-
自定义表(自定义表中存放着数据库中的额外数据,后面会有讲解):
单纯的key-value结构。
自定义表中存放的是连接表与表之间的关系的数据,在之前的笔记中说明过:我们尽量避免表与表之间的物理关系,尽量采用逻辑关系,这种设计规范可以参照数据字典,数据字典中存放着各个表中的关键字段的值。
我们的自定义表就是所谓的数据字典表,我们的表间关系在业务逻辑层中解决。即之前正常的表连接查询等操作在数据字典中可以执行多条查询语句来完成,这样在效率上会有很大的提升。同时也会解决表间关系复杂导致操作数据库过于复杂,甚至可能出现数据库崩溃的现象。
-
-
-
建立E-R图(根据分析的角色以及需求来建立表间关系):
- 分析表间关系(用实体关系图来说明一下各个角色之间的关系):
上图表示的是实体之间的关系,比较乱。此图仅用作理解角色,具体关系在下图E-R图展示:
【注】:虽然在实体关系图以及E-R中有相应的表间关系,但这只是逻辑关系,我们尽量只要数据库中存在物理关系。也就是说,我们逻辑上认定表与表之间的关系,这一层关系在业务层中来解决。
图中的dict 表就是所谓的自定义表(或称字典表)。在标准的数据库规范设计中没有字典表的概念。字典表的概念来自于基于基本的数据规范衍生出的新的数据规范,即在普通的规范中引入一个做中间表的字典表。
在上面的图中,我们仅做了一部分角色之间的关系图,除此之外还包括关注、粉丝、评论等相关功能,评论功能在此不做说明,单纯说明一下关注与粉丝的实现(仅说逻辑,不会说明具体实现):
一般来说,关注与粉丝的功能有两种解决办法,分别使用两种技——MySQL或NOSQL(通常为Redis或MangoDB):
-
MySQL解决办法:
初学者在实现这个功能的时候一般会选择在用户表中加入关注和粉丝字段,将该字段类型改为list,然后将关注的用户或者该用户的粉丝的主键(id)按照列表的格式存入该字段,在此郑重说明,这个方式不正确且会造成数据冗余。正确方法如下:
一般会单独创建一个表,这个表字段并不是很多,其中包括关注人的id 和 被关注人的id,这样我们需要在页面中显示出关注和粉丝数量的时候只需要通过条件来查询这个表即可得到该数据;
如果需要显示关注或者粉丝都有哪些用户,则可以通过遍历该表得到的对应id 来查询用户并将其显示到页面上。
-
NOSQL解决办法:
一般NOSQL数据库被我们称为缓存数据库,其实它不单单用于缓存数据,由于在某些方面它的效率会优于关系型数据库,所以我们常用它来与前端连接,为前端提供一些数据。我们可以在NOSQL中存入各个用户对应的关注与粉丝id 列表,提供给前端快速响应。
【注】:NOSQL中存入对应用户列表的方法与在MySQL的用户表中增加字段的方式看似一样,其实不然。首先,MySQL与NOSQL的执行效率不一样,NOSQL要更快一些,其次,我们在用户表中增加字段将会增加空间复杂度,而且在执行过程中会造成业务逻辑过于复杂。如果通过增加外键的方式来存储,我只能说:孩子,你太天真了……
总结
本篇笔记中举了一个不是例子的栗子,其中仅仅说明了一些逻辑和思想,具体实现一毛钱都没说。经常看我笔记的同学们可能会理解。我的笔记一般只记录逻辑和思想,有了逻辑和思想后,想学什么都会很快,理解能力很更强。具体实现的话看视频会更直观,不过众所众知,博主很懒,不录视频……