※ 引述《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)