※ 引述《liton (歐吉桑留學生)》之銘言： : ※ 引述《liton (歐吉桑留學生)》之銘言： : 抱歉 前篇快睡著了沒說清楚 : 我前面兩篇有說到一個技巧 : 搜尋數字會比搜尋文字快 : 如果acc_no真的是數字 那這技巧又沒用 : 但一般而言 帳號資料會是文字格式 : 所以我的建議是先做個數字編碼的對照表 : ... : 當然前提是你不是在你最重要的moment來執行這一段 : 而是先前在做資料大表或universe的時候就搞定 : : : → azimuth:另外我是按acc_no大小從readall49抓出觀察值,如果我先對 03/18 : : → azimuth:readall49按acc_no排序 這樣系統處理會比較快嗎? 03/18 : sort最有效的地方 : 是在資料合併的時候 : ... : 所以在你的情況下 有沒有sort完全沒差 恕刪 感謝指教~ 嗯 我的帳號本身就是數字 所以就以原本程式來看 應該是算ok了 也許只是因為資料真的太大吧?! 不過這個問題我後來解決了 方法就是: 對readall49的acc_no做INDEX 之後使用PROC SQL抓每個帳號觀察值的時間幾乎只要1秒 另外歐吉桑提到的UNIVERSE 請問這個是什麼?? --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 140.115.220.209 ※ 編輯: azimuth 來自: 140.115.220.209 (03/19 22:07)