铁道部 12306 网站的设计最近颇招非议，除了成本高昂之外，设计不透明，交付产品看起来粗糙，订票流程问题多多，铺天盖地的非议就出来了。但是我们可以想象，即便是再糟糕的一个系统，也一定有大量的人员在投入探讨他们的解决方案。在 ITPUB 论坛上，看到一些知情人士的记录，可以一窥这个网站背后的一些真实情况。
本文实属摘录，主要来自网友 yulihua49 的记录，以下最初的讨论内容来自2012年1月，现在情况应该已经有了一些的不同。
1.数据库与平台
12306的架构比较复杂，基本售票系统是SYBASE，网络订单数据库是ORACLE。
最初性能低下的原因不在数据库，而在安全网闸。
原来一个网闸处理全国业务成了瓶颈，将来每个局一个网闸和一个出口带宽，有望缓解。
铁科研那帮人搞了这么多年的大并发处理，经验还是有的。能想的办法都想了。
关键是SYBASE不给力，换ORACLE难了，全是存储过程，移植到ORACLE，前几年试过，不敢上线。
但就一般情况来说，数据库还不是瓶颈，仅仅在某些极端状况下是数据库。
网售更不是数据库瓶颈，网闸那儿档着，请求都进不来，数据库根本不忙。
有人，还号称是专家，说关系数据库不灵，要用TPF什么的劳什子，更是屁话，在相同配置下TPF比ORACLE慢几十倍，试过的。
2.关于网络订票只能买到上铺的说法
关于订票分配的规定： 一张：中，2张：上下，3张：上中下。
但是实际，卖乱了，就乱七八糟碰运气了。
窗口可以选铺别，有时为了多完成收入指标就先把下铺卖光了。 网售在窗口之前，还不至于被抢光
3.关于前期开发和设计
人员就是清华的一帮。网站开发是铁科院和清华易程竞标，清华没中标。 他们想用IBM的TPF，就是航空订票的那个60年代的东西，太古老了。实际上根本不适用。 95年IBM就找到我们推销TPF，被我们否了，09年又来了，撺掇易程。5个人花了3个月，测了一下，根本不成。
4.关于Oracle数据库
关于基本订票系统Oracle替换Sybase，铁科院试过了，可以但是不敢用。
一个是已经买断了SYBASE的版权，再花钱买ORACLE，给个理由，领导说。
一个是大规模的移植和培训。
一个是谁也不敢说不出娄子。
SYBASE用了10年刚刚使系统稳定下来。谁敢说改ORACLE能稳定？
16年来，几代人在SYBASE上写了数千个存储过程。没人知道那个有用那个已经过时了。
后来问了一下铁科院，存储过程可以查孤儿，所以没用的都剔除了，但是常剔常出，还是有。 另外剔除孤儿很危险，如果一个应用在SQL里写了一个调用孤儿的就。。。。。。
以上的讨论清晰的说明了一些问题：
1.铁路的基本订票系统，使用的是Sybase数据库，评估过Oracle，但是没有彻底替换的决心；
2.12306网站的订单系统使用的是Oracle数据库，2012年初的主要问题出现在网闸上，数据库端压力不大；
3.现在12306的问题体现在排队上了，问题已经转移。
ITPUB 讨论链接： http://www.itpub.net/thread-1565638-1-1.html