2023数据库课设经验分享

我的数据库课设与我的一些看法

首先，我的选题是火车票售票系统，所以我的讲解很多会以此为例，我的老师是李晖老师，不同老师风格有有所不同，所以如果你有验收等等方面的问题，最好咨询一下对应老师带过的学长学姐。

其次，我依然觉得数据库课设是一次非常重要的锻炼个人实际开发能力的机会，如果你觉得自己毕业后大概率做开发工作（前端、后端等等），那么数据库课设是一次非常好的锻炼自己能力的机会（当然，对于软工来讲，你也可以选择做算法岗、运维，产品等等）。

此外，针对软院培养方案来讲，你的数据库课设在后续课程中大概率会被多次复用。以我个人为例，我的数据库课设在暑假结束验收完后拿了A，大三上软件工程实验我们复用了一次数据库课设（当时用的是我队友的，问就是我懒），大三下项目管理也会用到（不过当时我直接拿i山大举例了），如果你选了刘士军老师的服务开发这门课，那么还会用到一次（这次用的是我的，队友保研线边缘挣扎，我没啥保研希望比较闲，直接把整个实验全包了，最后拿了个99，可能跟我的课设更偏向后端有关）。所以有个成熟、完整而熟悉的项目对你后续课程帮助还挺大的。

最后，我个人对数据库课设的总体看法也很简单，这个课设的目标其实跟PPT里写的一样

数据库课程设计的目的是让学生在掌握数据库的相关理论知识后，将数据库与软件开发相结合，熟练掌握数据库设计和基于数据库的应用程序开发，实现一个完整的以数据库为核心的应用系统。

这个目标跟现在的大部分服务软件思路是一致的，即用户-前端-后端-数据库，或者说，开发一个基于数据库进行服务提供的应用程序。软院课设基本可以分为开发型与研究型，开发型就是基于某种技术进行软件开发（将技术变现，在开发中学技术），比如java课设、web课设，研究型就是基于所学知识对进行研究性开发（将理论知识变现，对理论性的知识进行实际应用），比如计组课设，操作系统课设，不过这种分类并不绝对。数据库课设基本偏向于开发型。

个人认为的最佳实践与关注点

老师的建议是七月规划，八月开发。我个人对此没什么意见，我心中的最佳实践大概是这样的：

规划阶段：

拿到题目，根据自身实力水平圈定一定的题目范围，针对这些题目的业务复杂度展开调查，了解某一系统大概要做哪些东西，结合自己假期可用时间选一个理想题目。
针对选定的题目做更详细的调查，重点关注包括但不限于：具体业务逻辑范围，业务大概的实现逻辑，核心功能有哪些，对应是怎么实现的，UI设计（有无竞品参考），数据库设计与关注点（前人踩坑的地方）。能顺手记录一下更好。
设计、打磨数据库结构，设计一个大致的ER模型与对应的数据库表，注意针对自己理解的业务逻辑进行优化，在前期排除ER中一些不合理的地方。
设计系统架构，确定技术栈与整体的系统结构。注意这部分是不涉及业务的。

开发阶段：

根据自己对系统的理解进行开发，在此过程中关键在于不断根据实际开发需要优化数据库设计（不如一些不合理的表的关系，不合理的数据类型等等），我个人更推荐的开发流程是：确定实现某一功能，先写前端，理清逻辑与设计到的数据结构，并且确认其在其他功能中大概率可以适用之后，完成前端开发，根据前端需求开发后端，在开发过程中检验数据库设计的合理性并做出修正。说白了，是一个需求驱动的过程。
- 当然，开发之中顺手记录下自己遇到的困难与解决思路，将会在写报告时大有裨益。

我的数据库课设

先看看效果，截图在这学期服务开发课复用时候做的PPT的最后。

项目在github：

https://github.com/ZWN2001/TrainServerSpringboot

https://github.com/ZWN2001/TrainClientFlutter

我翻看了当时的commit记录，发现我的过程基本就是七月设计八月开发。首先我了解了域模型、DDD、CQRS 与 12306 的设计，大致确定了系统核心逻辑：票务所涉及的逻辑难点与更高效的实现思路，确定了我要做一个支持高并发量的秒杀系统，也了解类似系统的设计思路（读写分离，但实际上只有一个数据库，所以，分了，但没完全分），了解了我可能用到的技术栈（尤其是后端，除了springboot，Mybatis之外的Redis，RabitMQ等等），对自己的整个课设过程有了一个大致的预估和规划。

然后针对系统我完成了技术栈选型（基本上就是了解的那些），完成了系统架构，如图：

然后完成了ER模型设计，顺手把表SQL写了一版（这里是最终版，不过我还是认为有不妥之处）：

然后我就去照着最初的表爬数据去了，前前后后去12306爬了3000K行数据作为系统的数据源，但现在看来还是十分不太明智的，因为数据库的设计还没有最终确定，贸然爬数据不是一个特别好的选择，虽然我个人将其看做前期准备中的一部分，但不得不承认存在后期整理数据甚至需要重新爬的麻烦与风险。

八月我进行了开发工作，不过当时先写了后端再去做前端还是给我造成了相当多麻烦，同时，我认为这个过程中我顺手写的文档帮了我很大的忙，同时也直接成为了实验报告的雏形，毕竟对于程序员来讲：

最后也算是勉强完成了开发工作，由于整个系统非常庞大，跑起来要占我电脑基本90%的资源，所以没法开腾讯会议演示，最后就放了段演示视频交报告zip完事。

我的一些建议

针对规划与开发

如果你此前已经认真在做课设并且已经做了很多设计或者开发工作，我认为当下重点在于打磨自己的系统与文档，去思考，你的设计是否合理，代码维护性可读性是否还过得去，在做的时候有没有顺手把自己的所思所想顺手记录下来，能不能在所有开发结束后整理一下就能形成报告的雏形，而不是挖空心思回忆自己一个月前在干嘛。

同时，大家都做这个系统，你的系统比别人好在哪，功能更多更全？性能更强？设计更巧妙？UI更多更好看？交互逻辑更简单易用？系统完成度更高？用到了什么出众的算法？等等等等，让老师能看出你的亮点。

如果你刚刚开始，还没有下手，我觉得关键在于快速成型。首先，不妨先花点时间，选一个简单些的题目，花几个小时去看看每个题目所涉及的业务细节，有没有什么比较复杂难以实现的地方，毕竟就算是火车票售票，其实也涉及换乘、分座等等复杂逻辑，确定一个逻辑相对简单的题目，不至于后续开发遇见难以实现的复杂逻辑而拖累进度。当然，最好能找到一些比较成熟的DEMO，直接在这个基础上去改，添加自己的东西，相对来说快很多。

其次，在设计功能时，你应该划分核心功能与非核心功能，核心功能其实就是系统运行必须有的（PPT里其实写了很多），非核心功能是可有可无的，比如支付采用支付宝沙箱等等，开发时先保证核心功能的完成度，保证在验收时能展示，不扣分，然后再去完成非核心功能，尽量保证所有功能的完成度

最后，无论如何，请确保你的功能符合日常使用认知，这一点非常重要，比如火车，不能中途换座，飞机对时区的考虑，餐馆允许加菜等等，如果在使用逻辑上出了问题，说明你的软件设计与需求分析不到位，会给你的演示成绩带来损失（如果被老师发现，至少李晖老师是这样的）。你问我明明是数据库课设老师为什么关心这个，我只能说，因为你做的是软件，是面向用户的。

针对报告与演示

针对演示

演示是跑系统为主，不是从头到尾对着PPT干讲。

演示关注系统功能性、健壮性和易用性

加分项：功能完善、界面友好、容错性、用户体验良好、有一定业务流程、先进的框架和插件、角色划分明确。

我们当时的演示时间是8分钟，对于我的火车票售票系统来说是不可能将所有功能演示完的，所以我也只是演示了核心功能（票务，买直达，换乘，付款，退票，改签等等）。

其次，我认为非常重要的一点就是，演示关注的是功能性、健壮性和易用性，换言之，看的是你前端的水平（虽然我对此颇有微词），也就是说，如果你想在演示中获得老师很大的好感，那么你的系统UI要好看，交互要合理。

软院课设向来喜欢看脸，想要UI好看就用现在主流框架，Vue，React等等都可以，他们往往都有各自的组件库，能让你免去自己设计组件的烦恼，可以轻松有一个风格统一而好看的界面。

交互的合理性更考验的是你的设计能力，如果你真的没有什么前端设计经验，我的建议还是参考一些demo，哪怕直接抄12306呢，当然，只要能保证界面排列整齐、重点突出、交互逻辑合理，我认为就还算不错。交互逻辑的合理性一定程度上体现在点击次数，如果你的系统不需要经常点来点去才能完成一个业务，那我认为交互合理性就还不错，当然，也跟系统整体的交互逻辑有关。

谈到健壮性，主要还是一些非法字符、SQL注入风险等等，我的建议是，后端一定要有错误检查，前端如果有时间写的话，可以直接前端拦截，但后端一定不能少。

针对报告

课程设计报告关注点：

系统需求分析
系统设计，重点是数据库设计
系统实现

需求分析其实就是我所说的前期规划阶段，我们对系统业务进行了解的过程其实就是需求分析的过程，总之就是要阐述整个产品所实现的功能，要达到的效果。

系统设计包括架构设计与数据库设计，架构设计只需要放一张架构图，谈谈自己的设计思路与理由即可，数据库设计我主要关注了核心功能的场景下，一个业务从功能需求到数据库对应表的设计的整体流程与设计思路，其实就是讲为什么要这样设计这几张表。归根结底，数据库设计是受业务逻辑驱动的，所以其设计也必定离不开你所进行的逻辑设计。

系统实现就是业务具体的实现原理或逻辑，我认为重点在于讲清楚后端针对关键功能进行的业务设计与思考，此外，也可能有一些关键性的概念，比如我的火车票系统就将每一趟车次的站与站之间划分了“原子区间”，这对我的系统来说是非常重要的概念，就必须进行详细的解释：为什么要有这个，有什么好处，以及实现方法等等。