数据库设计心得——五班再卷紫砂辣
项目简介与背景
“新冠”疫情爆发后，“健康码”通过大数据赋能，为统筹做好疫情防控和加快恢复生产生活秩序提供了有力支撑。“健康码”起源于疫情，已广泛使用于机场铁路、道路卡口、医院药店、企业园区、住宅小区等各类公共场所，有效地支撑疫情防控和复工复产。随着我国疫情进入“后疫情”时代，“健康码”系统在疫情常态化防控中发挥着重要作用，成为公共场所做好常态化疫情防控不可或缺的利器。本系统立足于湖南省，搭建湖南省健康码系统，用以改进完善当前“湖南省居民健康卡”相关功能，助力政府做好疫情防控。
相比之前的健康码，我们的健康码相比之下更加简洁、可适用的范围更广。在使用过程中，减少一些用户的麻烦。内容更加多元化，弥补了诸如管理者的需求功能空白。
团队介绍
项目名称：健康码管理系统
指导老师：边耐政
小组名称：五班-再卷紫砂辣
小组成员：张弘骏、兰凯伦、李亚宸、谭吉、唐典、张笑睿
数据库设计重要性
数据库设计是计算机软件设计的核心部分，由于计算机软件设计工程师的层次不同，导致不同的软件工程师在对于计算机软件设计的出发点的理解上并不相同，有些软件工程师更加注重的是业务功能模块的实现，在接收到应用程序的需求文档之后便迅速投入到软件开发的工作中，在数据库的设计上只用了较少的时间，并且思考的点仅仅注重在功能模块的实现，并没有真正意义上的思考数据库的性能以及后期维护等等。而这种不负责任模式通常是致命的，对于软件应用程序会留下非常多的隐患，这些隐患有可能会在程序开发过程中出现，也有可能会应用程序运行很久之后出现，造成应用程序崩溃，还有可能对于软件系统的后期维护工作带来非常多的麻烦，当问题出现的时候再优化数据库或者修改等于应用程序重新开发，即浪费人力也浪费财力。
也就是说，糟糕的数据库设计会导致数据冗余、存储空间浪费，甚至出现修改处理复杂化、操作数据异常等情况，而良好的数据库设计能够节省数据的存储空间、保证数据的完整性、保障系统的安全可靠运行、方便进行数据库应用系统的开发，进一步提高系统性能以及降低后期维护成本
设计过程与设计概述
第七周，根据数据库设计规范，参照项目需求文档，小组内成员（主要为后端的开发者）进行多次组会讨论，着手进行项目数据库的设计。并且分工合作，完成数据库设计文档初稿
第八周，结合指导老师的建议，对数据库设计文档进行修改、迭代
设计心得
张笑睿：
-
两表的主键互为外键：
在设计时，为了体现两表之间的关联性和可维护性，我们设计了一些外键。但是在实际使用中就遇到了两表互为外键，例如区县防疫办的id作为超级管理者的外键，而超级管理者的id也作为区县防疫办的外键。这就导致了在第一次新增数据时，由于两表都为空，无法使用外键，从而都无法顺利的插入数据。发现这个问题后我们又重新检查了设计好的数据库，最终觉得按照管理关系，去掉区县防疫办中关于超级管理者的外键，从而顺利的插入数据。
据分析，两表主键互为外键应该是一个设计问题，类似与死锁，并不合理，在首次插入时会造成极大问题。如果两表主键必须互为外键，可以在按照以上方法插入数据后，再重新设置外键；如果两表中已经存在其他数据对象，先插入的对象还可以先引用表的其他对象作为外键，待二者都完成插入，再修改外键。
-
物理删除和逻辑删除：
由于一些外键的存在，我们在某些情况下不方便将数据对象直接从表中物理删除，这是就需要在表中添加新字段
deleted来标识这个对象是否被删除，其中0表示未删除，1表示删除。当我们使用mybatis-plus框架时，对数据执行删除操作，就会自动将deleted字段赋为1，并无法查询。如果使用自己设置的查询语句，则应注意在需要时手动添加判断deleted是否为1的条件。 -
乐观锁的应用：
为在保证数据库读写效率的同时，防止在并发操作时出现线程安全问题，我们在数据库中添加了version字段。当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据。需要注意的是，我们需要添加项目的配置文件来启动乐观锁机制。
兰凯伦：
1. 关于主键id的问题
最开始我们的主键id统一设置为了int类型，后来为了照顾自动生成id的雪花算法，又统一将数据库id类型改为了long类型的。但是后来又发现有部分表的id用字符串来表示更加合理，但是这次也没有再修改了。所以之后的建表过程中应该先考虑好不同表的主键id的合适的类型，不应该全部统一为一种格式
2. 关于关联表之间的修改问题
由于表与表之间的关系错综复杂，并且表的结构创建好之后不能够轻易修改关联的部分（比如修改被其他表设置为外键的字段），如果需要修改则要先移除关联再进行修改，属实麻烦，所以在构建数据库之前应该尽量避免再次修改标示为键的字段
3. 关于一些增加的字段
在后期编写代码的过程中，往往会发现数据库一些疏漏的地方或者缺失的功能，比如逻辑删除。这时需要在各个表中统一增加字段。这个问题相对来说容易解决一些，毕竟可以批量操作表。但是，这种修改成本会随着项目的推进而增加，所以在数据库设计前期应该尽早发现一些潜在的问题，宁可多增字段，不可缺少字段
李亚宸：
通过这次的数据库设计，我明白了一个良好的数据库设计不仅会满足用户的需求，还会对程序开发有很大的作用。这个过程并不那么简单，而是比较复杂的。在设计的过程中组内成员经过多次讨论协商，对整个数据库的设计改了又改。总结出来以下问题：
一、 字段
默认值： 数据库所有为NULL 的列需要额外的空间来存储，因此会占用更多的空间；也尽量不要使用数据库默认值，数据入口保持一致性，都是从java实体传递过来比较好，数据库默认值增加数据来源并且切换数据库容易出现问题
时间尽量不要用数据库函数来写，MySQL主从同步会造成时间差，最好用datetime。
二、 命名规范
数据库所有对象名称均使用小写字母，并且单词之间通过下划线分开；
数据库所有业务表，前缀均使用项目名称或者模块首字母缩写；
数据库所有存储相同数据的列名和列类型必须保持一致。
张弘骏：
因为我们小组项目采用的是类似统一软件开发过程或者敏捷过程，所以在设计过程中，需要经常与指导老师进行需求的沟通，这也导致了我们的项目用例和功能也会产生变化。
因此，在在数据库建表时要考虑到以下两点：
1. 打出冗余量，对于一些目前尚未要求和实现的功能，提前建立表和属性，由此减少未来修改的时间
2. 要求对不同表和其之间关联非常熟悉，由此便于数据库的修改与更新。
唐典：
在数据库的设计过程中，我们遇到了很多问题，比如个人信息需要存储多少，各表之间的相关联系，时间字段需要设置哪种类型。虽然都很头疼，但在大家的一致合作下还是完成了数据库的设计。
虽然这样，我们在使用数据库时也遇到了一定的问题。比如区县管理员和超级管理员表中都存在着管辖地区的地段。但由于我们在设计表时地区表精确到了区县，就导致超级管理员的地区字段并不是外键类型，没有起到我们想的约束作用，这也是我们设计数据库之后没有进行一个细致全面的检查的问题。这也提醒了我们在设计数据库的时候要多注意各个不同表之间的相互联系，做到没有遗漏。