之前開發一套車輛管理系統，車籍資料超過80個欄位了，一開始會異動的資料在一個表格，不會變動的在另外一個表格，熟悉DBMS的大大一定知道為什麼這是災難的開始。
資料庫管理系統，課程主要精神就是在教EDR與正規化，正規化很重要，一個系統的效能在於適當地切割資料表，沒有正規化的資料庫，很容易發生資料不匹配的問題，而導致於coding時事倍工半。

修課當時，也只是照著課本做，其實對於如何合適地使用SQL語法，是上班之後的事了，不過我覺得對於語法效能最有幫助的課反而是Data Structure，order by就不用說了，排序最少是O(N*logN)當我下了一個group by或者union，腦袋瓜要馬上閃過big O，在實際上執行時，花費的時間複雜度是否可以接受。

另外，偶而會幫忙同事turning語法，新手最容易犯的錯誤，就是查詢網頁時，資料看不到，原因就在於inner join與left join的不同。

再來是索引的運作，大部分的所以都是使用B-Tree結構來節省查詢的時間，樹狀結構可以把線性搜詢所需要的O(n)時間，reduce到O(logN)，如果資料結構B-Tree的那個章節有認真學的話，使用B-Tree的好壞處很快就可以理解，自然也知道最適合加入索引的時間。

之前開發一套車輛管理系統，車籍資料超過80個欄位了，一開始會異動的資料在一個表格，不會變動的在另外一個表格，熟悉DBMS的大大一定知道為什麼這是災難的開始。這樣設計的下場是甚麼呢？就是超級慢的查詢速度。

車籍資料有4000筆，兩個表格進行join後，產生4000*4000這麼大的笛卡耳積，先不論資料庫系統進行的什麼優化，或者有設定索引，光就時間複雜度的觀點，就慢了4000倍，這80欄的車籍資料，在大部分的頁面，都需要讀取兩個表格。

後來跟我同組的同事討論後，決定合併這兩個表格，結果速度就馬上有明顯的提升，代價就是，全部的code翻起來review一次。所以系統的最終儲存目的地是資料庫，而不是自己維護的檔案時，這時候熟悉資料庫結構就很重要。

資訊學院的30門課-課程一覽表