車牌辨識系統全面上路快一個月了，當然還是在測試調整的階段，這段時間我多半在忙著處理明顯的辨識錯誤，以及伺服器資料流量的問題，就是讓資料處理可以跟得上兩百多個監視器持續收錄的資料。當然處理辨識完畢就是進到資料庫以備查詢了！之前趕著驗收時，合作的嘉義世新有線電視公司的程式師好心幫我建立資料庫以及查詢網頁，所以我很高興少了一項沉重的工作。但是現在看來我高興得太早了！

目前已經知道每個監視器會找到可能有車牌的照片平均一天約5000張，全嘉義市總資料量一天就是一百萬張上下！合約規定至少要留存備查兩個月內的資料，那就是六千萬張了！資料量之大確實遠超過我以前的資料處理經驗，蠻恐怖的！即使也是資料庫程式高手的世新公司程式師，剛建好資料庫與網頁時就說，他也沒面對這種資料洪流的經驗，不敢保證資料較多時資料庫與網頁能夠正常運作。果然！當資料量多到千萬筆以上時，搜尋動作就開始慢到要以分鐘來計時！這當然是業主無法接受的結果。所以啦！幫忙的程式師兩手一攤，說還是請聰明的張院長親自出馬解決吧！

好像這是我的命格？我這輩子似乎所有困難的事都必須自己來，毫無僥倖，逢賭更是必輸！別人很少可以順利幫到我的忙。昨天運氣好，一天都有空，好好的研究了一下這個問題。首先從之前處理伺服器資料塞車的經驗知道，當單一目錄檔案數太多(幾萬以上)時，光是開啟目錄就很耗時。同樣的道理，一個資料庫的單一資料表內資料筆數高達百萬以上時，也是光載入索引就很耗時。原來的設計是一個伺服器對應一個資料表，一個月資料總量三千萬張，除以7大約就是四百多萬張，開起來就是很慢。

所以啦！首先是要設法將資料表實質切割，如果以天(日期)來開資料表，一天還是有一百萬張，有可能還是慢。所以乾脆每日每站各自建立一個資料表，這樣單張資料表內的資料最多一萬筆(不含圖檔)上下，一眨眼間就打開了！麻煩的是這樣切割之後，程式會變得複雜很多。首先必須用到在程式內增刪資料表的程式，我之前只是聽說過，但還沒實際用過。而且每次搜尋時就不再是找一個資料表了，而是數十、數百甚至上千個表，但是實際比對的資料數，比全部搜尋是少很多的！這樣當然會比原本大海撈針的方式快，但是必須更聰明與細心的寫程式，指定出真的可能有資料的表格，預期速度會比目前的版本快很多。

因為這次改版連資料庫也必須大改，所以我不準備繼續在他們既有的PHP+MySQL架構之下改建，直接就用我熟悉的ASP.NET與微軟資料庫來重建了！好消息是：當我改建成功後，整個系統徹頭徹尾所有軟體就真的都是我做的！硬體也都是我們公司的人採購、安裝與維護的！本公司真的就此有了一套可以供一個縣市規模來使用的車牌辨識系統完整技術了！據老闆說：下一站彰化縣，我們就要來了！