C#、LINQ與ADO.NET主從表比對操作

上傳的數(shù)據(jù)可能存在版本不一致，基礎(chǔ)信息都不會有變化但擴展的表或字段會不存在，原因是客戶端存在沒有升級的情況。

系統(tǒng)從Access數(shù)據(jù)庫文件中取數(shù)據(jù)，使用整合后把相關(guān)數(shù)據(jù)并統(tǒng)計后對數(shù)據(jù)進行入庫到系統(tǒng)數(shù)據(jù)庫。部分的字段不能直接入庫需要進行轉(zhuǎn)換處理。由于數(shù)據(jù)庫數(shù)據(jù)在進行操作時已經(jīng)不會產(chǎn)生任何的變化。可以把數(shù)據(jù)都預(yù)先讀取到內(nèi)存當(dāng)中。從而產(chǎn)生數(shù)據(jù)臨時存放容器選擇為IList和DataTable選擇。

表A為主表：外表操作以表A為切入口, 根據(jù)表1 的某人字段從而選擇當(dāng)前記錄行的子信息來源，關(guān)聯(lián)字段要用到兩個字段才能唯一。主表對從表的關(guān)系為：一對多的關(guān)系

表B為從表1：

表C為從表2：

把數(shù)據(jù)源轉(zhuǎn)成實體操作

好處：操作直觀，操作的字段不用每次比較時都進行比較。

缺點：性能不高。一個月的數(shù)據(jù)上百條記錄用時幾秒，一年的數(shù)據(jù)上幾千條記錄統(tǒng)計整理用時5分鐘。數(shù)據(jù)量越多性能越明顯。

ADO.NET

直接把表數(shù)據(jù)都查詢出來沒有任何過濾條件。在進行從表查詢時不進行對實際的數(shù)據(jù)庫文件進行操作。

好處：通過主表查詢從表的記錄信息在性能消耗并不高。同一文件一個月數(shù)據(jù)用時1秒之內(nèi)，一年數(shù)據(jù)10秒之內(nèi)。

缺點：操作并不直觀，每次比較都要進行強制轉(zhuǎn)換格式。后期有業(yè)務(wù)規(guī)則變化不好處理。

采用支持關(guān)聯(lián)查詢的ORM框架

好處：不用處理再次查詢的操作，而且能用實體操作更為直觀。

缺點：市面上沒有支持Access的ORM框架，而且一般流行的ORM框架都以配置文件使用。不方便動態(tài)變化的上傳文件名。

現(xiàn)在項目處理方案：

由于方案三先使用起來比較麻煩要自己好寫底層類。Ado.net做操作查詢?nèi)缓筠D(zhuǎn)為實體進行統(tǒng)計。發(fā)現(xiàn)真實使用時和直接采用方案二的時間一樣。原因可能是從表查詢才是性能的主要瓶頸，轉(zhuǎn)為實體不是并不是什么性能問題。

如果采用方案三的方式又可以在查詢DataTable這個處提高更多的性能。并且減少浪費內(nèi)存資源不像現(xiàn)有方案用了同一數(shù)據(jù)占用了兩份資源。

備注：為什么沒有真實的數(shù)據(jù)報告。主要當(dāng)時沒有想到要寫這篇文檔，就沒有把當(dāng)時使用的數(shù)據(jù)保留下來。不能一味聽到別人說那個好那個不好那跟著別人走更多的時候是要有實踐。個人覺得現(xiàn)在的ORM框架是很好用很方便邏輯和代碼的處理，但遇到現(xiàn)實中的情況就有點力不從心（如表多了少了、字段多了少了等等）。更多時還要自己寫處理方案來確保性能。還真的很久沒寫博客了這編的主要是體現(xiàn)個思想和不要人云亦云。

服務(wù)器租用/服務(wù)器托管中國五強！虛擬主機域名注冊頂級提供商！15年品質(zhì)保障！--億恩科技[ENKJ.COM]