最近各位常來的讀者知道我在忙車牌辨識系統的流量，也就是處理速度的問題。比較沒提到的是資料處理完畢之後，如何寫入資料庫？以及如何有效地搜尋資料？的問題。因為在尖峰時刻每秒鐘需要寫入資料庫的辨識結果高達六七十筆！而且會隨機的來自七台不同的電腦伺服器，他們不會講好誰先誰後，做完一筆就丟一筆！如果都是以HTTP通訊模式傳到資料庫，因為速度較慢，常常產生碰撞或來不及完成寫入動作，該寫入資料庫的資料就遺失了！

也因此，過年前老闆最大的困擾(壓力)是負責與嘉義市警局對口進行系統教育訓練的有線電視公司的工程師說：他的車天天上班經過應有辨識系統的監視器，卻常常找不到資料，讓他自己都對系統沒信心了！我和老闆當時都沒答案，所以年假開始時大家心情並不太輕鬆。現在知道照片確實有照到，也辨識正確完成了，只是寫入網路資料庫時失敗，所以事後搜尋不到！

時間再往前轉一下，剛開始是有線電視公司負責開發資料庫系統的，但是僅僅十天的資料量就讓他們的設計產生問題，因為資料量太大，搜尋時間變得長到不合理(幾分鐘)，而且當時兩百多台監視器其實正常運轉的還不到一半！如果真的要塞滿合約規定的兩個月資料，那麼找個車牌可能需要吃一頓飯的時間！問到如何改善，有線電視的工程師兩手一攤，就說看看「張院長」有沒有辦法囉！

所以啦！我被迫重頭建立了一個資料結構更靈活，且欄位資訊更精簡的資料庫架構，可以讓搜尋速度回歸到十秒左右可以忍受的範圍，如果搜尋條件設得詳細，更可以一眨眼就找到。因為精簡資訊，我的資料量是原資料庫的約十分之一，資料表則拆得很細，不用每次搜尋都要打開大到有幾百萬筆資料的資料表，當然速度就合理了！只是寫入資料庫的程式變得比較繁瑣，因為入庫時就要分別寫到很多不同的「小房間」而不是原來的「大通鋪」。

大年初一我發現了這個資料會遺失的大漏洞，接著一兩天就改用另一種保證不會漏失資料的方式寫資料庫，再「反芻」舊資料，就是將處理過的照片再跑一次新的程序，結果那位工程師的車子就陸續出現在搜尋結果裡面了！老闆知道後當然龍心大悅！

關鍵是我知道HTTP效能就是比較差，而且七個伺服器任何時間都可能送資料，也就難免會互相碰撞(同時要求網站寫資料)。所以我在各伺服器程式中將必須寫入資料庫的資料寫成文字檔案，約三五秒一次，以FTP將此文字檔案傳到資料庫伺服器那台電腦，再用一個長駐的小程式監看這些傳入檔案，依據內容依序寫入資料庫，就不是經過網站，而是在本機電腦裡面像檔案處理一樣寫資料庫，依序處理各伺服器來的資料檔，這樣決不會碰撞遺失資料，而且速度還很快！一秒上百筆都不是問題。

我好像太大方地洩漏了我的商業機密，但是說實話我還算是新手，我想真正的高手公司或許技巧更好，即使有誰學去了我也是很高興的！反正資訊技術日新月異，等著申請專利的時間裡，我的小撇步可能早就被新技術取代了！我只希望我的老闆與業主能夠知道我的心血努力，不要太輕忽了我的工作價值，沒給我適當的酬勞也就算了，還常常給我一些愚蠢的任務，好像我吃飽太閒。

譬如老闆傳來訊息說：有線電視公司希望我的資料也能回頭饋入他們的舊資料庫系統，因為當初教警員使用的是舊的網頁系統介面，希望舊系統也有資料可以查詢。因為我的資料結構全改了，要回頭寫程式將新資料改成舊資料格式寫入舊資料庫很費事，最莫名其妙的是：寫回去幹嗎？

要不是舊系統根本跑不動，我也不必重建資料庫，不是嗎？現在資料已經多出十倍之後再寫回去那個資料庫，就反而可以轉動了嗎？而且他們的搜尋介面簡陋得很，並不好用，比我們新寫的介面(還提供網路地圖)根本不能比！為何不是稍微學一下新網頁的操作，而是回去使用找一個車牌要半小時的卡卡系統？

看起來要他們相信我的專業能力還需要一段時間，我不抱怨人常常會提出一些可笑的建議，我也會！但是我不滿意的是他們並不是問我這樣好不好？與我討論之後決定做不做？而是直接要求我做這種傻事！好像他們都比我更懂這些事該怎麼做？渾然忘記是因為他們卡住了才找我解決問題的，我真的都不知道該怎麼說了？