※ 引述《Adonisy (有梦见鬼，烧炭相随)》之铭言： : 需求:看看能不能集结成文章,下次投到杂志 : (1)连线系统,目前有板桥,桃园,新竹,台中,嘉义,台南,左营 : 采分散式架构,每站都有柜台负责线上订票,未来站可能会增加 : (2)在购票前,需知道车次或发车时间,起点-->终点,商务或经济舱， : 　　　　　　偏好靠窗或靠走道 : 　　　　 (3)同车次，起点到终点间的位置，不能重覆售与第二人 : 　　　　　　例如板桥到台中若与 100车次 1车厢 1号售与甲 : 　　　　　　　则 桃园到台南 100车次 1车厢 1号，就不能售与乙 : 　　　　 (4)同车次，起点到终点若错开，则可重覆售与第二人 : 　 : 　　　　　　例如板桥到台中，100车次 1车厢 1号售与乙 : 　　　　　　则台中到左营，100车次 1车厢 1号可以售与丙 : 　　　　　光这四点，我想就可以搞翻天了．．． my god.... : 　　　　　　我想，资料库不能设计成批次处理，因为划位时就要选位了 : 　　　　　　用 web server来做，在柜台不太适当 : 　　　　　　如果以後开放网路订票，应该也只能订到票，然後到现场划位才行 : 　　　　　　 (有些东西还要再改) 最近资料库设计课程,还是硬头皮设计出来了...人工选位 实体: 车辆:车次,起站编号,迄站编号,发车日期时间,抵达时间,剩余座位, 商务容量,经济容量,靠窗容量,走道容量,南下北上 车站:车站编号,站名,地址 订票资讯:车次,发车日期时间,车厢,座号,起点编号,迄点编号,身份证护照编号 停靠站资讯:车次,停靠站编号 座位资讯:车次,发车日期时间,车厢,座号,靠窗,订位,处理车站编号,经济, 起站编号,迄站编号 网路订票资讯:身份证护照,订票时间,车次,发车日期时间,订票张数, 经济,靠窗,起站,迄站 车辆也可以分为两个实体,因为车次相同,但发车时间不同,则视为不同车 其观念与杂志有多少期是一样的道理 此次设计分为两个阶段,第一阶段是使用者查询几点几分由甲地到乙地的高铁资讯 (票价还没加入,可自行加入) 这部分比较简单,因为每天开的高铁,同车次的起迄点与途中站是一样的 第二部分则是订位资讯 座位资讯是在输入新的车次与时间时,自动产生出来的位置 例如: 103次 2007/09/10 07:00 台北发车的班次 在资料库中建立这笔资讯时,座位资料已经产生出来(假设有1000个座位) 车次 发车日期时间 车厢 座号 靠窗 讧位状态 处理车站 经济 103次 2007/09/10 07:00 1 1 0 0 1 0 103次 2007/09/10 07:00 1 2 1 0 1 0 ... ... 103次 2007/09/10 07:00 10 50 0 0 7 0 也就是说,我们划的位置,已经事先在资料表中建立,订位状态是0 表示这个位置没人订 而处理车站则代表有哪些车站的柜台可以对这列资料处理? 如果没有处理车站这个属性,则订位是全台抢位系统 但我事先把座位1000位,依车厢与车站分别设定好,可以把抢位状态减到最低 例如,台北保留 400位,台北站的柜台只能看到这400个座位,其他600位看不到 板桥保留 300位,桃园保留 150位... (愈来愈少),到了左营就是保留0位 因为在左营柜台没有人会买左营到左营的南下列车,所以左营柜台不用保留 如果北上就是左营保留位置最多,台北是保留0位 这样可以有效减少资料库同时抢位锁定的问题,台北站的竞争者是台北站其他柜台 不是其他站的柜台 当然,到底每站要保留多少位置,是经验法则,真的位置用完了还是可以看 其他保留位 这个资料库有很多地方没有正规化,但是没办法,就是为了效能的反正规化 等会要下课了,有空再贴後半段 在网路上找到的文章 http://www.zdnet.com.tw/enterprise/column/cio/0,2000085687,20115201,00.htm 谣言1:高铁系统是机场订位系统改的 如果是这样,真该死 http://tinyurl.com/2ekde2 谣言2:高铁系统没用资料库 呃..... --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 59.124.169.51 ※ 编辑: Adonisy 来自: 59.124.169.51 (09/27 16:01) ※ 编辑: Adonisy 来自: 59.124.169.51 (09/27 16:02)