关于一个长途汽车和火车票的预订、售票系统的实现方案征集意见

黄叶

老兄，你的这个项目应该是在软件界做得比较成熟的了，可以多借荐其他软件的开发模式。
我想开发一个系统最重要的几个方面应该都要兼顾到吧。
第一：当然是稳定了。
第二：代码可扩展性。
第三：才是易用性了。
一个象你这样的系统很难说采取什么C/S或者是B/S来开发，通常象这种系统开发出来后都是象这种形式的：一个强大的后端处理平台+多种灵活的前端应用方式。在有部门有可能是C/S，有的部门可能会给它一个中间件+一个前端，也有的应用就是用一个浏览器+WEB+后端的处理形式。所以我认为这种系统最重要是先把后端的数据处理平台做好。然后再考虑前端平台的制作。后端的数据处理平台的设计应该是比较难的，既要考虑到稳定，又要考虑到可扩展性，数据库非Oracle莫属了，然后数据库是有了，但是网络方面也要充分的考虑，比如说你的这个系统在处理某一个地区的数据时它的性能是足可以应付了，但是如果随着业务的扩展，系统性能明显的或者跟不上形势了，这这时候可能或者想到要将数据处理以分布式的系统来处理，如果你原来做这个系统的时候没有考虑到，造成你现有的系统无法扩展，那么你原来所有的努力都将白费了。最可怕你的是你的数据怎么办？
在POS处理上有个说法叫断网收银，也是基于这个原因来考虑的。但是收银系统应该不会有你这个系统那么大。所以后端处理平台是重中之重，这个做好了，再说其他的。个人认为你这个系统应该是多人，多专家同时会诊才不至于挂万漏一。我要去开会了，回来继续聊。

kj501

他的这个系统只是为了作演示。所以我想只要能演示出一个分布式数据库应用系统的特点就行了。如果要当成一个实际项目来做，几千元的经费，能干什么？

kiron

最初由 黄叶 发表
老兄，你的这个项目应该是在软件界做得比较成熟的了，可以多借荐其他软件的开发模式。
我想开发一个系统最重要的几个方面应该都要兼顾到吧。
第一：当然是稳定了。
第二：代码可扩展性。
第三：才是易用性了。
一个象你这样的系统很难说采取什么C/S或者是B/S来开发，通常象这种系统开发出来后都是象这种形式的：一个强大的后端处理平台+多种灵活的前端应用方式。在有部门有可能是C/S，有的部门可能会给它一个中间件+一个前端，也有的应用就是用一个浏览器+WEB+后端的处理形式。所以我认为这种系统最重要是先把后端的数据处理平台做好。然后再考虑前端平台的制作。后端的数据处理平台的设计应该是比较难的，既要考虑到稳定，又要考虑到可扩展性，数据库非Oracle莫属了，然后数据库是有了，但是网络方面也要充分的考虑，比如说你的这个系统在处理某一个地区的数据时它的性能是足可以应付了，但是如果随着业务的扩展，系统性能明显的或者跟不上形势了，这这时候可能或者想到要将数据处理以分布式的系统来处理，如果你原来做这个系统的时候没有考虑到，造成你现有的系统无法扩展，那么你原来所有的努力都将白费了。最可怕你的是你的数据怎么办？
在POS处理上有个说法叫断网收银，也是基于这个原因来考虑的。但是收银系统应该不会有你这个系统那么大。所以后端处理平台是重中之重，这个做好了，再说其他的。个人认为你这个系统应该是多人，多专家同时会诊才不至于挂万漏一。我要去开会了，回来继续聊。

不错，我觉得重点的确是要放在后端数据处理上，和我的想法不谋而合。
我们对这个项目的开发很看重，虽然只有几千块，但是能批下来已经是学校做的最好的支持了，我们希望可以在比赛中拿到好名次，所以我们会尽一切可能做到最好的，在大学能开发出这样一个系统，也算是一个不错的成就了。

这个项目在七月暑假就开始了，在下还有许多不懂的地方，到时肯定会遇到许多困难，除了我们会努力解决外，一定还会麻烦到兄弟们，请不吝指教。谢谢。

jerboa

我个人感觉：实际上数据库部分相对容易些。无非是考虑好数据结构以及将来的扩充性，其实ORACLE这方面已做的很好，有好多方案可供。要紧的是要了解需求，先前没有看到《项目说明》，以为数据量不大，起初以为是一个日流量1000----10000人左右的规模，现在看来一天50万也可能上的(不包括峰值)，因此非ORACLE莫选了。
按上面的《项目说明》我认为数据库方面，所需要的各表并不多，无非建客户要查询的各车次的表以及索引，或根据几个相关的表建个视图即可，比起企业的系统容易的多。各表关系好比较明确。

我现在根据《项目说明》设想大概所用的表如下：

1)操作员表：控制各人员的权限及口令以及其它信息，如活动、停用等等。
2)车次表：记录各车次、座号、价格表、出发点、目的地、预售票数、已售数、其它。这个用来客户查询、以及车站广告牌动太广告用。
3)售票状态表：车次、座号、金额、出售形式(订票、柜台销售)、其它
4)客户表：客户信息、车次、座号、金额、证件号码、电话号码、其它。
5)退订表：客户信息、车次、座号、金额、证件号码、电话号码、其它。退订后把车次、座号重新更换回未售出状态。
6)临时车次表：同车次表，适应适时增加车次的情况。
7)人员流动统计表：这个是根据以上数据，分析人员流向，以利于车次调度。
8)当日金额统计，包括各售票点售出票数统计，收入金额以利于业务人员复点。
9)月度、年度报表，包括本年度也历年度的对比、同比等等。
10)其它表，一些用户要求的内容实现。

注：其中各表中“其它”是一些未考虑的情况。

你最好先拿出概要设计方案与详细设计方案与用户讨论才行。

黄叶

数据设计可不光是建立表的问题。
一个大型的应用要达到要求，不能说是建建表，建数据库就够的。后端的数据平台可不光是一个数据库管理系统能够达到的。一个好的后端数据平台包括很多的方面的。如果说它这个仅仅是一个演示项目，当然没有必要考虑得那么清楚了，但是如果真的是一个大型的应用，光是后端的数据平台的搭建就要花去一大半的时间，后端的开发也很重要。后端应用可不是只包括建建数据库表这么简单吧。

kj501

如果真的按照实际项目来做，要考虑的事情就实在是太多了。就拿全国铁路订票系统来说，那么大的信息量和地理分布范围，是把数据全部集中到一个中心还是每个省建立一个中心，然后在这几个中心之间保持数据的同步？这对于数据库在分布式处理上的性能自然要提出很高的要求。再有，如何保证24X7的高可用性，系统的安全性和可靠性如何实现，这些都是很专业的问题。
做一个有一定的伸缩性小系统来演示是可以的，但这种伸缩性不是无限的，就象你可以根据一个小的轮船模型做一个大一点的轮船模型，但不可能完全按比例放大去造一艘真正的轮船。

kiron

最初由 jerboa 发表

你最好先拿出概要设计方案与详细设计方案与用户讨论才行。

详细设计方案还没有做出来，项目正式在七月开工，到时我会把我们讨论的详细方案发上来和大家继续讨论，以后陆续会在这个帖子里发我们的进度，请大家继续关注这个帖子。

kiron

最初由 kj501 发表
如果真的按照实际项目来做，要考虑的事情就实在是太多了。就拿全国铁路订票系统来说，那么大的信息量和地理分布范围，是把数据全部集中到一个中心还是每个省建立一个中心，然后在这几个中心之间保持数据的同步？这对于数据库在分布式处理上的性能自然要提出很高的要求。再有，如何保证24X7的高可用性，系统的安全性和可靠性如何实现，这些都是很专业的问题。
做一个有一定的伸缩性小系统来演示是可以的，但这种伸缩性不是无限的，就象你可以根据一个小的轮船模型做一个大一点的轮船模型，但不可能完全按比例放大去造一艘真正的轮船。

嗯，在火车方面的实现是比较困难，由于我国的铁路是国家统一管理的，这样一个系统太大型，我们没有打算做这么大的，可以从一个大型长途汽车站的规模来考虑，管理本站的发车，订票等数据就可以了。

jerboa

呵呵，大家说的规模越来越大了。现在界定一定的范围还比较好办的。
现在《项目说明》仍然需要说清楚，是要全省所有的汔车要联网还是单独一个车站呢？是将来准备数据共享还是单独使用？单从用户投资角度来看，这个系统采用oracle已早超过预算了。用户是否基于够用就好？还是准备大量投资搞它？
一些问题必须说清楚大家才能进行正常判断啊。

kj501

是呀，最关键的就是用户需求，需求分析在实际项目中可是非常困难也是非常重要的。