矩陣維度不高，而且都是隨機存取的話，建議乾脆丟 DB
DB的設計就是要讓大量資料隨機存取用的
只要有正確打 key，隨機存取的速度可以很快

有現成工具可以用，沒有必要重造輪子
況且將來還可以無痛轉移為平行運算用

~~~~~

先求有，再求好，有時間就改程式，一般來說都是沒時間，所以都叫客戶加RAM、換CPU，這樣省事多了，其實巨型陣列也是一種演算法，只不過比較簡單而已，簡單通常
不容易出錯，就算出錯也比較好除錯，當然客戶也知道買RAM比改程式便宜，免等待
立即有效，所以巨型陣列架構，是本人及同事寫程式的標配，算是同事們認同，長官裁示
准予執行的設計模式。

說真的，我也需要時間陪家人，員工手冊可沒寫，老婆跑了，公司包賠。
看演算法的書，坦白說，只是在家人面前裝很有學問的樣子，還由就是同事間互相調侃的
工具，用了XX演算法，而被查覺者，罰海產攤請客。

以上為個人經驗，因所處環境不同，最好不要參照執行，切勿自誤，如有冒犯，祈請見諒!!

如果是業界，有很大的時程壓力，當然是先求有，再求好。
可是樓主是學生(因為樓主在他的文裡有提到老師)，既然是學生，幹麻不挑戰一下「求好」的作法？
如果弄的好的話，這個作品就是他有日去業界找第一份工作時的本錢。

當真加ram最快解決?
如果我告訴你, 很多問題其實花個1,2個小時想一下就可以編個適合的演算法來解決了, 不需要什麼複雜的數學演算法, 你們覺得如何?
你們用這種心態在寫軟體當然永遠都想不到,

總之, 基本 programing 太差這些事情是永遠都想不到的, 不想用腦筋那就別再做這一行了.

加 RAM 只是時間、空間二擇一的選擇，附加的是免除更改系統的風險，保證系統穩定度。

因為看不懂演算法書籍上的專業說明，所以我與同事們都自行構思解決方法。

在程式碼中，看不出使用演算法的痕跡，這是我與同事間的小遊戲。

因為客戶端的要求，嚴格的反應時間，自然是用陣列而非串列，以取最少的指令耗用。
當初制定系統架構時，已具備如增加執行緒、記憶體，系統可自動校正參數升級。

個人比較喜歡活的程式，我的人如果交寫死的程式碼給我，那會同樣死得很難看......

寓遊戲於工作中，寫程式碼不太像工作，比較像藝術。

周末時間，堅決不接觸與工作有關的事物，夜深人靜，該去做家事了.......

講到寫程式是藝術這件事，我想到一些有趣的事。
曾經讀過一些文獻，在探討一些跟寫程式有關的東西，我覺得最有趣的一件事是，該論文提到，同樣的問題，給十個人寫程式解決，會出現十種不同的程式，而能正確解答的可能是八個，但是那八個的程式用的方法卻很可能都不會一樣。
這也是為什麼程式開發方法一直是上世紀末到這世紀的研究目標... 程式工具進步神速，但開發的本質從以前到現在並沒有多大變化...
所以其實我們提供的都是建議而已，最佳解不一定只有一個，這就是程式的有趣之處。

因為你的工作不算是對效能、資源限制要求很高的吧，例如 embedded system, 因為成本考量, 系統資源都是設計在最低限度。不要以為到處都幾GB RAM, 幾 TB storage space, 有些系統是用 "MB" 來計算的，如果你的 embedded system 只有32MB的RAM, 32MB 的 flash size, 這可不能讓你隨意揮霍系統資源的。

加RAM? 一個 embedded system 可能才賺 1美金，再加RAM就要脫褲子了，並不是說加就加的....

或遊戲或一些對效能、空間要求嚴格的應用程式，你的遊戲畫面沒比別人好，佔用RAM卻比別人大很多或 Frame rate 比別人低，玩家一定狂幹的啊，「最佳化都不會做，出什麼遊戲~~」之類。

還有你自己想出來的方法也是演算法了，不是書上寫的才叫演算法。
再者演算法只有好的和不好的，沒什麼活的死的，多看書才能知道更多的好的演算法，也有肋於自己想出更好的演算法。

忽然想到一個例子，大學時老師出一個點燈問題，因為老師只出 5x5的棋盤，所以同學都用暴力法解決。每一個格子可以點亮或關閉，用暴力法複雜度只有O(2^25).

但如果用暴力法處理 20x20 的棋盤，需要 O(2^400)複雜度，遠超出人類電腦的能力了；但我想到一個很棒的演算法，只有O(2^20)複雜度，甚至比用暴力法處理 5x5 的棋盤還快。

這個方法我展示給老師看，老師很驚訝地看著我，問我怎麼會想得到，我說，靈光一閃就想到了~~

不過世界上聰明的人很多，後來發現這個方法早就有學者想到，並做更深入的研究了。
所以有時候你可能根本不用自己想，靠別人的成果就可以大幅改進自己的程式效率了。