主题：【原创】身为码农，为12306说两句公道话 -- 代码狗

现在的问题应该是查证实名属于凭空多出来的工作量，铁路职工热情不高敷衍了事。如果规定凡查到冒用他人身份坐车（票、证不符）的，奖励一半的补票费用，肯定就轻松解决了。

帮别人订票的输错身份证号码是正常错误。

这个思路是不错的，不用弄的很死，可以退票但是票款锁定，用户凭自己的身份证和订票人的身份证去手工验证退票款。

增加黄牛的成本。

在这里SKUn的查询只需要有一个实时更新的SKU1~SKUn-1的最小值，最小值大于1就可以出一个SKUn了啊。是不是只要对SKUn的商品配以一个SKU1到SKUn-1的最小值，然后只查这个值就可以了，不过这个值的同步是个问题。

虽然12306没有和公安的系统联网，也不至于随便写一串数字就接受。

主要针对楼主的这段话：

查询性能在这里不是问题，因为查询本来就不应该直接去访问余票数据库，而是应该为余票数据库建多个定时更新的只读副本，把所有的查询流量分散到这些副本上，余票数据库只服务最终下单的请求。这样做的缺点是查询结果和实际余票情况在一定时间内会存在不一致，可能查得到票却买不着。但这在很多人同时下单买票的情况下本来就无可避免。

从服务最终下单操作的请求来看，16 种商品的方案明显优于楼主提出的 136 种商品的方案 —— 这点楼主是否同意？

还是有很大的不足，没有考虑每张车票它的座位属性。这个是很要命的，不然大家好不容易挤上车，就开扁了--抢座哈。当然，开扁这是我编的。甚至考虑这样一个方案：设G71总共有M个座，16个站段，那就是16*M个商品，也避免不了座位属性。主要是因为卖出2个站段及2个站段以上的车票，在方案中也就是2个商品，这2个商品的座位属性必须是一个座位。

关于库存数据存储设计，我再提一个方案，不用16个商品也不用136个，只用1个，但是不存储“库存数量”，而是用一个bit vector代表整个路线的存货，查询和购买都只用一次操作。

北京西到深圳北就是一个16位的bit vector，初始状态全部是1。

查询1号站到5号站就是查询:

1111 1111 1111 1111 AND 1111 0000 0000 0000 == 1111 0000 0000 0000

查询只用一次操作，得TRUE

如果这张票卖出去了，那写入也只是一次操作:

1111 1111 1111 1111 - 1111 0000 0000 0000， 得新值0000 1111 1111 1111，写入。

下一次查询比如2号站到6号站：

0000 1111 1111 1111 AND 0111 1000 0000 0000 == 0111 1000 0000 0000 得 FALSE.

读写兼顾，而且数据库维护很容易，没有任何多余重复信息。

虽然不懂技术，但楼主这么一分析，明白了许多

和136种商品没本质区别

无可厚非，反正用户不接受的淘汰就是了。但是在一个高度垄断的行业如此行事，那就不是个体行为了，侵害的是全体公众的利益。

不管南方系出于什么样的目的反对这一点，但是反对这一点本身无疑对公众有利。

至于淘宝不帮12306解决问题也会损失公众利益，这当然是事实。但是把那些本身有能力有意愿为公众提供更优质服务的公司挡在为公众服务的可能之外更会导致公众利益受损。前者导致的损失远远小于后者，因为后者是涉及方方面面的、长期的(一般来讲在体制存续期内是永远的)、隐形的(这导致的问题尤其严重，12306的问题无非是表现出来，而且被媒体高度曝光成为众矢之的的，那些损失更大却没有得到重视远远多于一个12306吧，不明白的可以重读一下忘情的帖子)。

一个车次上千个座位，你要匹配上千次，效率不高啊~~

在乘客随机购买不同区间座位的情况下，的确会产生这样的情况：你要的乘车区间在细分到每一个原子区间之后，每个原子区间都有座，但却对应于不同的座位。考虑到有人愿意买七八张车票接续回家，也许将来乘客愿意接受每过一个站就换一次座位的方案

好像铁路现在对这个问题的解决方案是，卖给你一张无座的票，你上车后自己找座位。

差了一个数量级啊，这套系统的关键之一不就是维护量的庞大吗？

http://news.qq.com/a/20140115/004909.htm?ADUIN=534733126&ADSESSION=1389702743&ADTAG=CLIENT.QQ.5281_.0&ADPUBNO=26292

好像铁路部门不认为联网认证会拖垮相关系统

不见得每一个人都可以找到抢票软件帮忙吧？