推 ephesians:即時顯示的方案...嗯......踩地雷!? 140.137.2.48 01/08 11:43
※ 引述《ephesians (ephesians)》之銘言：
: 我不認為該如此設計呢...
: 應該是這樣說,使用者能夠掌握的資料是:
: 1. 他想要買哪一班次的多少張票.
: 2. *希望* 座位在什麼車廂及靠窗靠走道.
: (在此特別註明是 *希望* 而不是 "指定",
: 因為系統可以在沒有滿足顧客所希望座位的時候,給予其餘建議)
: 3. 結果,得知訂位是否成功.
: (若成功,就知道是配給哪幾個座位; 若失敗,原因多半是座位不夠)
: 至於即時的座位訂購情形,最好不要顯示.
: 因為只要顯示了座位表,就要為了作座位的即時動態顯示而作mutex之類的事,
: 對客人來講也很麻煩,看座位表買票,就好像看股市走勢圖做買賣一樣.
: 上述是我之前提到人力售票的意思.
hm..
這應該是為了顧及人機上的選擇而已。 :Q
依照你所描述的使用者自我掌握，還是包含他想定的座位票次，
重點只是在於「即時與否」。
小弟覺得要顯示是因為可以讓使用者先知道「此座位可不可以選」
考慮一個使用者在選位置時考慮很久的情況：
有即時顯示：
0.座位表以每秒 1-5 刷的速度（看 loading 程度而定）向主機取得正確表次。
1.使用者在操作完成之後，看著座位表，猶豫 5 秒後對目前空的座位指定。
2.訂購成功/訂購失敗（此種訂購失敗只存在於零點幾秒以內的同時指定吧）
3.失敗，從座位表選出下一個位置。
好處：．每次失敗所消耗時間累計起來不會太高。
．比較可以避開有五個座位卻十個人在定的不必要情況。
缺點：．要用 mutex 之類的方式作即時。
沒有即時顯示：
0.取得目前的座位訂購情況。
1.使用者完成操作，開始輸入自己顯做的位置。
2.訂購成功/訂購失敗（此種訂購失敗有可能在使用者還在考慮時候便已成立）
3.失敗，重新輸入下一個要選的位置。
每次失敗所累計起來的時間相較之下比較高。
好處：．系統的負擔相較為輕。
缺點：．每個使用者在操作到「訂購已經被人先定走的座位」此錯誤時，
使用者要花較久的時間才能察覺，形成無謂消耗。
．中控端演算法的需求相對要很高。
或許如您所言，是該回到半人工/半系統方式，像訂購機票一樣，
但這樣是否就失去了高鐵整體的快速和便利意義？ :Q
而且機票是在劃位時才能選擇靠窗或靠走道，
所以使用者或許會變得不能選擇座位。
題外話，我不相信花了人民多少億血汗錢的高鐵，
會拿不出一部分來作訂票系統的即時中控。 :Q
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 124.10.4.193
※ 編輯: gpmm 來自: 124.10.4.193 (01/08 10:39)