12307 火车票购买平台
内容提要
作者分享了大二数据库课程满分项目“火车票购买平台”，采用Flask后端和Vue前端，实现查票、中转、订票、余票及线路管理。疫情期间与队友线上结对编程，练习Git协作。文章重点讨论ORM局限：复杂余票查询直接写SQL更清晰；中转算法属多目标优化，采用按客流量加权枢纽站的启发式搜索。项目开源后曾被外校学生询问能否用作毕业设计。
延伸解读
ORM 的适用边界
作者在项目中指出，ORM 并非万能。对于火车票余票查询这类涉及多表联合的复杂逻辑，直接编写 SQL 反而更清晰、易维护。ORM 转译不透明，调试和架构调整困难，心智负担大。这提醒开发者：在查询复杂度高时，应权衡使用 ORM 还是原生 SQL，避免过度抽象。
中转算法的多目标优化挑战
中转查询并非简单最短路问题，需同时考虑中转次数、等待时间和价格，属于无最优解的多目标优化。作者采用启发式搜索，按客流量加权枢纽站，并避免从小站扩展边集，以提升效率。这反映了实际系统中算法设计需结合业务特点，动态调整策略。
线上协作与 Git 实践
疫情期间，作者与队友通过腾讯会议屏幕共享每晚结对编程，并借此熟练了 Git 的 rebase、fast-forward 等技巧。这种线上合作模式类似敏捷开发中的结伴编程，强调了好队友的重要性。对于学生项目，这不仅是技术锻炼，也是团队协作的宝贵经验。
Q&A
12307火车票购买平台是什么项目？
这是作者大二时数据库原理课程的期末项目，实现了查票、中转、订票、余票查询、线路管理等功能，后端用Flask，前端用Vue，最终获得满分。
这个项目使用了哪些技术栈？
后端使用Flask框架，前端使用Vue，并采用ElementUI组件库实现界面。
为什么在票务系统中不推荐过度使用ORM？
因为票务系统表关系复杂，余票查询需要7~8张表的联合查询，用ORM会生成冗长难维护的代码，心智负担大，调试和架构调整困难，直接写SQL更清晰。
中转火车查询算法是如何设计的？
中转查询是多目标优化问题，没有最优解。作者采用启发式搜索，按客流量动态提升大型枢纽站的权重，并在最短路算法中避免从小站出发拓展边集，以提升搜索速度。
项目开发过程中如何协作？
正值疫情期间，作者与队友通过腾讯会议屏幕共享线上结对编程，每晚一起写代码，并练习了Git的rebase、fast-forward等技巧。
这个项目有什么有趣的后续故事？
2021年，一位外校学生发邮件询问如何启动这个开源项目，想用它作为自己的毕业设计。
