这个工作日主要在和 MySQL 斗争中度过了。
在测试登录注册模块的时候，一直连接不上 MySQL，经过一番的斗争，总结出了五篇“问题解决”的博客，后发现是由于我没有设置MySQL的密码所致。
到后面对登录状态进行修改的时候，发现无法更新数据，学会了使用 mysql_error 捕捉错误，事半功倍、
又花了点时间在MySQL调优上，主要是有这么一个情境：如果用户发起登录请求，则需要判断该用户是否已在线，如果已在线则不予二次登录。在这里我想直接判断是否对数据库登录状态进行变更而判定该用户是否可以登录，但是发现无法获取 update 影响的行数。因为如果是账号密码错误或者二次登录，所影响的行都是0，只有正确登录的情况下所影响的行才会是1。很可惜，经过测试失败了，想了想，MySQL毕竟不是特别擅长，还是先把基本功能做完吧。
在一天的努力之后，我意识到，SQL语句薄弱对开发进度的影响实在是太大了，需要专门去练一练了。 这里的薄弱指的是没有联表查询等操作的潜意识，这对未来技术发展也是一个硬伤。
受制于此，今天没有把剩下的业务都做完，而是再度优化了一下数据表。果然我还是太急了，没有把问题想清楚。目前我采取的策略是：想清楚一个功能，然后写一个功能，然后测试一个功能，持续集成（第一次体验这种模式）。但是现在我就发现了这个模式的弊端，我后面的业务会受制于一些全局变量，而如果要修改这些全局变量，则前面写好的功能多多少少会有一点影响的。
所以，我决定，要从全局出发先把所有业务都设计好，然后再一个一个业务去写，在写的时候也不断的重新思考，那时候如果还觉得要对设计调优，那也得调，但是绝对不会像现在这样频繁的觉得设计的太辣鸡了。持续集成是没有问题的，问题出在一开始没有全局考虑。 年轻人，还是年轻了。
新表设计： 中心思想：一个动车号在一个时刻只能有一班动车。
这个表直接砍的快没了哈哈。
这是一个极简主义者应该做的！
顺便改了一下设计图，主要是把ORM拿掉了。
