是否可以实现数据库表库与购票地点对应？
事实上我们都清楚公路电子客票只涉及终点与起点，因此在使用到同一车号的需要进行购票的绝大多数也将是终点与起点的城市。
那么，是否可以对应起点与终点城市生成相应的数据库表库，应该说是智能的分成相应的表库，并能实现对访问者的自动识别，进行数据库表库的分布式专项访问，加快数据库的响应速度。
2同行回答
车次信息包括起点，终点，途经站，渠道是否可售，余票信息，发车时间等，公路电子客票订单的生成应是在云中心进行，而时效性不高的车次查询，线路查询等可以分布式来加快响应速度。收起
使用云的架构看似解决了许多问题，包括系统的冗余、负载、大规模的并发。但大规模的云部署带来的也将是安全问题，对于已经可以形成自体网络架构的企业使用分布式部署，各自进行轻规模分布式部署是否能因此避免因云中心崩溃而带来的公众影响。而且对公路电子客票来说，旅客更多的是注重随到随行的感觉，习惯于至客车发车站点去购票，能习惯于乘坐下班次的客车。因此对于公路客票销售更重要的应该是票务信息的公开，同时能妥善地考虑到自身的交通状况。
- 您说的灾备方案，或者互相接管的问题。如果系统规模足够大，建立同城2站点，甚至2地三中心是必要的。同城实现互备，正常的时候，一个站点做业务经办，一个站点做查询服务，当生存站点故障，同城站点进行接管，两站点间数据同步复制。如果各自轻规模，就还是老问题，没法数据集中，数据是分散的需要大量的同步和交换，客票系统未来不走向集中，想实现航空和铁路的服务能力只能是空谈。