在本文LINQ中,匿名類型廣泛使用與查詢表達式中的select子句,它們返回查詢序列中每個元素屬性的子集.
在本文中ADO.NET，指定DbDataAdapter所生成的DataTable。
操作為兩個DataTable的查詢操作或兩個IList的查詢操作。
場景主從表比對操作：
上傳的數據可能存在版本不一致，基礎信息都不會有變化但擴展的表或字段會不存在，原因是客戶端存在沒有升級的情況。
系統從Access數據庫文件中取數據，使用整合后把相關數據並統計后對數據進行入庫到系統數據庫。部分的字段不能直接入庫需要進行轉換處理。由於數據庫數據在進行操作時已經不會產生任何的變化。可以把數據都預先讀取到內存當中。從而產生數據臨時存放容器選擇為IList和DataTable選擇。
表A為主表：外表操作以表A為切入口, 根據表1 的某人字段從而選擇當前記錄行的子信息來源，關聯字段要用到兩個字段才能唯一。主表對從表的關系為：一對多的關系
表B為從表1：
表C為從表2：
- 把數據源轉成實體操作
好處：操作直觀，操作的字段不用每次比較時都進行比較。
缺點：性能不高。一個月的數據上百條記錄用時幾秒，一年的數據上幾千條記錄統計整理用時5分鍾。數據量越多性能越明顯。
-
ADO.NET
直接把表數據都查詢出來沒有任何過濾條件。在進行從表查詢時不進行對實際的數據庫文件進行操作。
好處：通過主表查詢從表的記錄信息在性能消耗並不高。同一文件一個月數據用時1秒之內，一年數據10秒之內。
缺點：操作並不直觀，每次比較都要進行強制轉換格式。后期有業務規則變化不好處理。
-
采用支持關聯查詢的ORM框架
好處：不用處理再次查詢的操作，而且能用實體操作更為直觀。
缺點：市面上沒有支持Access的ORM框架，而且一般流行的ORM框架都以配置文件使用。不方便動態變化的上傳文件名。
現在項目處理方案：
由於方案三先使用起來比較麻煩要自己好寫底層類。Ado.net做操作查詢然后轉為實體進行統計。發現真實使用時和直接采用方案二的時間一樣。原因可能是從表查詢才是性能的主要瓶頸，轉為實體不是並不是什么性能問題。
如果采用方案三的方式又可以在查詢DataTable這個處提高更多的性能。並且減少浪費內存資源不像現有方案用了同一數據占用了兩份資源。
備注：為什么沒有真實的數據報告。主要當時沒有想到要寫這篇文檔，就沒有把當時使用的數據保留下來。不能一味聽到別人說那個好那個不好那跟着別人走更多的時候是要有實踐。個人覺得現在的ORM框架是很好用很方便邏輯和代碼的處理，但遇到現實中的情況就有點力不從心（如表多了少了、字段多了少了等等）。更多時還要自己寫處理方案來確保性能。還真的很久沒寫博客了這編的主要是體現個思想和不要人雲亦雲。