時下關(guān)鍵詞中，'低碳'出現(xiàn)的頻率那是相當(dāng)?shù)母摺！！＿溃雭砦乙材芩銈€百分之五十的環(huán)保主義者吧，比如，我吃肉，但如廁不洗手！哇哈哈。。。。
LingosHook怎么會有這個主題呢？是因為今天使用中，突然發(fā)現(xiàn)其數(shù)據(jù)文件（LingosHook.db3）變的很大，隨便抓取幾個單詞就上兆了，如果你使用的詞典較多（像Yu同學(xué)一樣。。。），那更是災(zāi)難。在我看來，一個符合'低碳'標(biāo)準(zhǔn)的程序，應(yīng)該是更少地占磁盤，更少地占CPU，如果能更少地占Network（高級程序才使用網(wǎng)絡(luò)的。。。），那絕對應(yīng)該可以打上個'符合低碳生活'的程序了。。。因此，這樣看來，LingosHook絕對不是這樣的程序。
回憶了一下可能的原因，發(fā)現(xiàn)是設(shè)計上的一個問題－－不同的單詞在WordTable中都有單獨一條記錄，這是應(yīng)該的，但問題是當(dāng)查詢'setting'時，LingosHook會將結(jié)果中的'set'也當(dāng)作獨立的單詞處理，這就導(dǎo)致在WorkTable中保存了兩份一模一樣的HTML數(shù)據(jù)，這個HTML數(shù)據(jù)的尺寸可不是小數(shù)哦。。。。嗯，這就是杯具的根源，要環(huán)保，要低碳，要改正。。。
修改上應(yīng)該不是很復(fù)雜，將Word和HTML數(shù)據(jù)分別存儲在兩個表（WordTable和SrcDataTable）中應(yīng)該可以了，使用SrcID作為兩個表鍵的索引。呃，容我下個版本改啊。。。這樣預(yù)示著，下個版本又要刪除數(shù)據(jù)庫文件了，唉，這個是我一直試圖避免的，這是設(shè)計能力不夠的表現(xiàn)。。。還有，HTML詞典數(shù)據(jù)的解析上還要下點功夫。。。