Re: [投書] 台鐵售票系統 瞎很大 (中時)

看板Railway作者 (歐吉桑留學生)時間12年前 (2012/07/25 20:50), 編輯推噓31(31推 0噓 67→)
留言98則, 22人參與, 最新討論串5/5 (看更多)
※ 引述《forcetrain (處女空氣)》之銘言： : 標題: Re: [投書] 台鐵售票系統 瞎很大 (中時) : 時間: Wed Jul 25 00:45:36 2012 : → liton:幾百萬做的玩的東西開到上千萬是等著讓財務砍賺點考績嗎? 07/25 01:43 : → forcetrain:全車自由席,就不用燒錢了 07/25 02:05 : → TimeEric:好奇有多少國家有寫出這樣的東西 07/25 03:42 : → TimeEric:如果這麼簡單的話 07/25 03:42 : → TimeEric:而且每個長途的都這樣搞 不就喪失配票的意義嗎 07/25 03:45 一語驚醒夢中人 配票是台鐵自己設定出來的 前端台鐵自己設的封印解除掉就行 報價上千萬根本是坑爹 但隨著時代的前進 得思考的是現行機制下能否保護小站乘客訂票的權利? 以前得現場買票 後來可以電話訂票 現在連超商也快可以直接訂票了 這樣保障的是誰? → forcetrain:反正改系統,換我去抗議了XD 現在對我來說很好訂 07/25 01:34 → forcetrain:正好把那些不善於訂票的人,先趕出場 XD 07/25 01:35 → forcetrain:訂票就是競爭,減少敵人就是增加訂票的機率 07/25 01:35 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 114.36.123.182
推
07/25 20:51, , 1F
雖然說解除就OK，但實際上會讓系統處理速度變慢
07/25 20:51, 1F
→
07/25 20:51, , 2F
所以電話會更難打通，網路會更難連上
07/25 20:51, 2F
→
07/25 20:51, , 3F
在小站臨時要搭對號車的人..
07/25 20:51, 3F
→
07/25 20:57, , 4F
少跑一段限制程式系統處理速度反而變慢?
07/25 20:57, 4F
推
07/25 21:08, , 5F
對，因為要搜尋的資料量變多。沒有區間配票時必須搜尋全區
07/25 21:08, 5F
→
07/25 21:08, , 6F
區間，有區間配票時只要搜尋涵蓋到的區間就好
07/25 21:08, 6F
→
07/25 21:09, , 7F
限制程式只是一個判斷式而已，複雜度大概O(1)，但搜尋區間
07/25 21:09, 7F
→
07/25 21:09, , 8F
的時間複雜度大概有O(n)
07/25 21:09, 8F
→
07/25 21:17, , 9F
"搜尋"的動作是很吃資源的,不要鬧了~~ 大家都不上,
07/25 21:17, 9F
→
07/25 21:17, , 10F
一樣不是一件好事情
07/25 21:17, 10F
→
07/25 21:23, , 11F
一班列車是幾個座位?幾千個?幾千萬個? 是同時搜尋N班列車嗎?
07/25 21:23, 11F
→
07/25 21:24, , 12F
google一秒內搜尋次數比台鐵訂位多太多了...
07/25 21:24, 12F
→
07/25 21:24, , 13F
怎沒聽說google有當機??
07/25 21:24, 13F
→
07/25 21:26, , 14F
一班列車是幾張配票幾張保留票?跑這段限制程式會讓搜尋目標
07/25 21:26, 14F
→
07/25 21:26, , 15F
區間少多少?
07/25 21:26, 15F
推
07/25 21:28, , 16F
呃...GOOGLE那演算法不知道是怎樣，非常強大...
07/25 21:28, 16F
→
07/25 21:28, , 17F
但好逮那不會是票務系統可以媲美的我覺得...
07/25 21:28, 17F
推
07/25 21:29, , 18F
樓上自己不妨假設看看一列自強號每節車廂52個位子，共13節
07/25 21:29, 18F
推
07/25 21:31, , 19F
共676個座位，假設北高停20站，每個位子就有190種組合，
07/25 21:31, 19F
推
07/25 21:31, , 20F
歹
07/25 21:31, 20F
→
07/25 21:31, , 21F
所以一列車的座位組合有128440種，而且搜尋時為了避免搶到
07/25 21:31, 21F
→
07/25 21:32, , 22F
相同的座位，還必須把座位暫時鎖住，大大增加搜尋困難度
07/25 21:32, 22F
→
07/25 21:33, , 23F
又假設使用者每次選擇的搜尋時段都是全時段00:00 ~ 23:59
07/25 21:33, 23F
→
07/25 21:33, , 24F
樓上你有在看本文嗎= =
07/25 21:33, 24F
→
07/25 21:34, , 25F
針對一比搜尋至少就要搜尋2568800筆，又同一時刻若有100人
07/25 21:34, 25F
→
07/25 21:35, , 26F
系統負荷量就再增加100倍
07/25 21:35, 26F
→
07/25 21:35, , 27F
台鐵目前可以搜尋特定時段所有列車哪班還有票?
07/25 21:35, 27F
→
07/25 21:36, , 28F
liton我認為你對電腦資料庫演算法並不是很懂，所以簡單舉
07/25 21:36, 28F
→
07/25 21:36, , 29F
個例子，希望能夠拋磚引玉一下
07/25 21:36, 29F
→
07/25 21:36, , 30F
lit大你自己在推文提的問題~ c大只是解答而已
07/25 21:36, 30F
→
07/25 21:36, , 31F
何來的有沒有看文章之嫌?
07/25 21:36, 31F
→
07/25 21:36, , 32F
我當然知道可以搜尋特定時段列車，但一般使用者怕麻煩都是
07/25 21:36, 32F
→
07/25 21:37, , 33F
選擇全時段，系統預設也是全時段
07/25 21:37, 33F
→
07/25 21:37, , 34F
你要指定車次也可以，但一般人並不會特別去記車次號碼
07/25 21:37, 34F
→
07/25 21:37, , 35F
排列組合就676選1!!
07/25 21:37, 35F
→
07/25 21:38, , 36F
樓上你這樣想就跟高鐵當時上路一樣，一個座位只能供給一個
07/25 21:38, 36F
→
07/25 21:38, , 37F
別激動~ 喝杯紅茶吧
07/25 21:38, 37F
→
07/25 21:38, , 38F
區間，然後其他區間全部死掉
07/25 21:38, 38F
→
07/25 21:40, , 39F
停20站就有20C19 = 380種組合，售出後填掉該區間
07/25 21:40, 39F
推
07/25 21:40, , 40F
沒錯沒錯
07/25 21:40, 40F
推
07/25 21:40, , 41F
這個正解
07/25 21:40, 41F
→
07/25 21:41, , 42F
然後每次搜尋時都得全車全區間找一次，台鐵的區間配位算是
07/25 21:41, 42F
→
07/25 21:41, , 43F
聰明的一種變通方法，只要統計特定區間剩下來的座位數就好
07/25 21:41, 43F
→
07/25 21:41, , 44F
不用搜尋整台列車的座位狀況，劃位就等賣票時再來弄就好
07/25 21:41, 44F
→
07/25 21:42, , 45F
更正20C19 = 190才對
07/25 21:42, 45F
→
07/25 21:44, , 46F
最後就等車票賣得差不多時，在開車前三天左右把區間限制拿
07/25 21:44, 46F
→
07/25 21:45, , 47F
掉，變成全區間，授權櫃檯售票員自己去切區間，把長區間截
07/25 21:45, 47F
→
07/25 21:46, , 48F
短售出，或是打出餘程無座這種的增加列車座位利用率
07/25 21:46, 48F
推
07/25 21:58, , 49F
立頓大的高中數學老師應該會哭，排列組合不是這樣算的
07/25 21:58, 49F
→
07/25 21:59, , 50F
單純對「坑爹」這個對岸詞彙反感
07/25 21:59, 50F
推
07/25 22:09, , 51F
代誌不是像O人想的那樣~簡單~
07/25 22:09, 51F
推
07/25 22:18, , 52F
cassine大還沒把座位配置跟同行人數等條件放進來呢...？
07/25 22:18, 52F
→
07/25 22:20, , 53F
買兩張票但不相鄰、買三張票分散在不同車廂....這都是現
07/25 22:20, 53F
→
07/25 22:20, , 54F
行配位方式可以直接省掉的困擾。
07/25 22:20, 54F
推
07/25 22:27, , 55F
現行的方式訂位跟劃位分開，所以可以再省去劃位的運算資源
07/25 22:27, 55F
→
07/25 22:28, , 56F
藉此提高系統尖峰時段的容量
07/25 22:28, 56F
推
07/25 22:29, , 57F
現在好像把定位跟劃位結合了，還是說劃位是台鐵後台即時處
07/25 22:29, 57F
→
07/25 22:29, , 58F
理？
07/25 22:29, 58F
→
07/25 22:36, , 59F
若是照原po要全車浮動訂位的話，勢必要在訂位的時候就劃
07/25 22:36, 59F
→
07/25 22:37, , 60F
好位吧？不然訂到位的會因為取票時劃位反而讓座位散掉。
07/25 22:37, 60F
→
07/25 22:39, , 61F
我是建議原po先把訂位的流程自己畫個簡單的流程圖想想
07/25 22:39, 61F
→
07/25 22:39, , 62F
或許就可以找到一些同時多人訂位系統的困難之處了。
07/25 22:39, 62F
推
07/25 22:43, , 63F
若是全區間然後訂劃位分開的話還可以利用維護時間跑動態規
07/25 22:43, 63F
→
07/25 22:44, , 64F
劃演算法讓座位配置最佳化，如果訂劃位合一就不容易最佳化
07/25 22:44, 64F
→
07/25 22:44, , 65F
但速度會比較快，畢竟動態規劃的複雜度隨便都O(n^2)以上
07/25 22:44, 65F
→
07/25 22:46, , 66F
拿Google來比是哪招 人家本業是什麼 有多少錢買設備? 有
07/25 22:46, 66F
→
07/25 22:47, , 67F
多少萬中選一的演算法精英? 你要不要拿你現在的電腦去跑
07/25 22:47, 67F
→
07/25 22:47, , 68F
台鐵訂票系統?
07/25 22:47, 68F
→
07/25 22:50, , 69F
對阿...而且GOOGLE的電腦不知道臺鐵的比不比得上OTL
07/25 22:50, 69F
→
07/25 22:59, , 70F
講了那麼多 跟配票的目的有啥關係?
07/25 22:59, 70F
推
07/25 23:04, , 71F
樓上的大大，人家很認真地在解釋你所提出的問題耶。
07/25 23:04, 71F
推
07/25 23:05, , 72F
樓上的大大，今天LCP乖巧嗎？
07/25 23:05, 72F
→
07/25 23:06, , 73F
達不到配票的目的卻拿配票當理由?
07/25 23:06, 73F
推
07/25 23:07, , 74F
我是覺得有人把問題想得太簡單，所以看不懂別人的回答
07/25 23:07, 74F
推
07/25 23:08, , 75F
請問liton，配票到底哪一點達不到了？台鐵配票失敗之處在
07/25 23:08, 75F
→
07/25 23:09, , 76F
於根本沒有按照市場需求來調整，配票的數量完全是照抄以前
07/25 23:09, 76F
→
07/25 23:09, , 77F
留下來的模式而不是真正按照需求去調整
07/25 23:09, 77F
→
07/25 23:10, , 78F
不然撇開市場供需不談，訂票系統運作地算是相當不錯
07/25 23:10, 78F
→
07/25 23:34, , 79F
依照現有接票盛行的狀況，台鐵可能根本看不清楚市場需求
07/25 23:34, 79F
推
07/26 00:22, , 80F
不懂演算法的不要太激動啦
07/26 00:22, 80F
推
07/26 02:15, , 81F
我也覺得有人把問題想得太簡單，所以看不懂別人的回答
07/26 02:15, 81F
推
07/26 09:00, , 82F
有強者可以評估以如此搜尋所需要的時間/資源嗎?
07/26 09:00, 82F
推
07/26 09:03, , 83F
國外有沒有網路訂票系統?
07/26 09:03, 83F
推
07/26 09:51, , 84F
前段搜尋符合時間起迄條件的部分，JR跟Yahoo!Japan 不錯
07/26 09:51, 84F
→
07/26 09:52, , 85F
但是對應到座位的部分就不是很確定使用狀況如何
07/26 09:52, 85F
→
07/26 09:52, , 86F
JR的網路訂位系統可以指定座位的樣子吧？
07/26 09:52, 86F
推
07/26 10:35, , 87F
沒辦法 某樓就是不知道講那麼多跟配票有啥關係(大笑)
07/26 10:35, 87F
推
07/26 12:46, , 88F
關於幾種組合的問題 可以把相近幾站設為一個群組
07/26 12:46, 88F
→
07/26 12:48, , 89F
ex:台北萬華板橋系統內當一組 桃園內壢中櫪也當一組這樣
07/26 12:48, 89F
推
07/26 13:33, , 90F
台鐵目前的區間配為就是像樓上講的這樣，部份區間內都一組
07/26 13:33, 90F
推
07/26 14:02, , 91F
人家在回答你的問題卻說人在「怕喇涼」..哈哈!!
07/26 14:02, 91F
→
07/26 20:06, , 92F
推文回答的不錯啊 淺顯易懂 代誌真的不想__人所想的這
07/26 20:06, 92F
→
07/26 20:06, , 93F
麼簡單 像
07/26 20:06, 93F
推
07/27 09:47, , 94F
這個高中排列組合有學好都看得懂啦XDDD
07/27 09:47, 94F
推
07/27 10:40, , 95F
台灣沒有像google那種人才 也許可以考慮委外
07/27 10:40, 95F
推
07/27 20:11, , 96F
光是655次的組合不用等到系統崩潰~~ 人腦就先崩潰了
07/27 20:11, 96F
推
07/28 19:11, , 97F
大家都忘了不是每個車站都有配位,台鐵有說過~
07/28 19:11, 97F
→
07/28 19:12, , 98F
硬是只訂某個區間,搞不好原本就沒有這種配票= =
07/28 19:12, 98F
‣ 更多 liton 的文章
文章代碼(AID): #1G3-jwVC (Railway)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 5 之 5 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共5篇)
‣ 更多 liton 的文章
文章代碼(AID): #1G3-jwVC (Railway)