你一直在说文件型数据库. 但是难道sql lite不是文件型数据库吗?
难道你以为在每一个读卡器里面还跑着一个数据库服务器吗?
嵌入系统使用的数据库哪个不是文件?
数据错误根本不是什么费率或者数据库数据的丢失, 而是读卡器里的数据和乘客卡里的数据不同步. 比如在读卡器里面已经记录了乘客下车, 但在乘客卡里却没有记录.
这涉及到和外设的通讯质量, 和数据库没有什么关系.
曾经看见一个所谓业内人士的分析, 他认为这个的产生, 和tap响应时间慢, 都是因为通讯上的问题. 他说每一次读卡算费和写回卡, 都有和中央服务器通讯, 确保数据的安全性. 但现实是大温的通讯网络质量不高(大温的地理情况决定了), 常常产生较长的的延迟. (这点在早期website的ajax程序中有类似的表现) 他认为translink应该考虑使用离线系统, 由每一个读卡器独立完成算费和写卡, 然后在确保通讯正常的时候再同步到中央服务器去.
translink的算费系统根本不复杂, 只是因为要分段计费, 就必然需要下车拍卡. 这点在前些日子公众认为既然目前的下车拍卡有问题, 那么为何不改变运行模式, 下车不用拍卡, 已开始translink硬撑, 认为可以很快解决, 但现在看来, 今年夏天说要实行的系统, 很可能就是取消下车拍卡. 毕竟 75%以上的线路都是在一个zone内运行, 乘公车跨zone的非常少, 许多还是在6:30p以后, 所以取消下车拍卡对translink带来的票务损失并没有多大. 何况这还只是过渡时期, 等translink解决了下车拍卡的问题, 再要求下车拍卡也不迟, 甚至要改变目前广被诟病的分zone也非常容易.