建站
咨詢
售后
建站咨詢
新聞中心
上傳的數(shù)據(jù)可能存在版本不一致，基礎信息都不會有變化但擴展的表或字段會不存在，原因是客戶端存在沒有升級的情況。
我們提供的服務有：網(wǎng)站制作、網(wǎng)站建設、微信公眾號開發(fā)、網(wǎng)站優(yōu)化、網(wǎng)站認證、青山ssl等。為上千多家企事業(yè)單位解決了網(wǎng)站和推廣的問題。提供周到的售前咨詢和貼心的售后服務，是有科學管理、有技術的青山網(wǎng)站制作公司
系統(tǒng)從Access數(shù)據(jù)庫文件中取數(shù)據(jù)，使用整合后把相關數(shù)據(jù)并統(tǒng)計后對數(shù)據(jù)進行入庫到系統(tǒng)數(shù)據(jù)庫。部分的字段不能直接入庫需要進行轉換處理。由于數(shù)據(jù)庫數(shù)據(jù)在進行操作時已經(jīng)不會產(chǎn)生任何的變化。可以把數(shù)據(jù)都預先讀取到內存當中。從而產(chǎn)生數(shù)據(jù)臨時存放容器選擇為IList和DataTable選擇。
表A為主表：外表操作以表A為切入口, 根據(jù)表1 的某人字段從而選擇當前記錄行的子信息來源，關聯(lián)字段要用到兩個字段才能***。主表對從表的關系為：一對多的關系
表B為從表1：
表C為從表2：
把數(shù)據(jù)源轉成實體操作
好處：操作直觀，操作的字段不用每次比較時都進行比較。
缺點：性能不高。一個月的數(shù)據(jù)上百條記錄用時幾秒，一年的數(shù)據(jù)上幾千條記錄統(tǒng)計整理用時5分鐘。數(shù)據(jù)量越多性能越明顯。
ADO.NET
直接把表數(shù)據(jù)都查詢出來沒有任何過濾條件。在進行從表查詢時不進行對實際的數(shù)據(jù)庫文件進行操作。
好處：通過主表查詢從表的記錄信息在性能消耗并不高。同一文件一個月數(shù)據(jù)用時1秒之內，一年數(shù)據(jù)10秒之內。
缺點：操作并不直觀，每次比較都要進行強制轉換格式。后期有業(yè)務規(guī)則變化不好處理。
采用支持關聯(lián)查詢的ORM框架
好處：不用處理再次查詢的操作，而且能用實體操作更為直觀。
缺點：市面上沒有支持Access的ORM框架，而且一般流行的ORM框架都以配置文件使用。不方便動態(tài)變化的上傳文件名。
現(xiàn)在項目處理方案：
由于方案三先使用起來比較麻煩要自己好寫底層類。Ado.net做操作查詢然后轉為實體進行統(tǒng)計。發(fā)現(xiàn)真實使用時和直接采用方案二的時間一樣。原因可能是從表查詢才是性能的主要瓶頸，轉為實體不是并不是什么性能問題。
如果采用方案三的方式又可以在查詢DataTable這個處提高更多的性能。并且減少浪費內存資源不像現(xiàn)有方案用了同一數(shù)據(jù)占用了兩份資源。
備注：為什么沒有真實的數(shù)據(jù)報告。主要當時沒有想到要寫這篇文檔，就沒有把當時使用的數(shù)據(jù)保留下來。不能一味聽到別人說那個好那個不好那跟著別人走更多的時候是要有實踐。個人覺得現(xiàn)在的ORM框架是很好用很方便邏輯和代碼的處理，但遇到現(xiàn)實中的情況就有點力不從心（如表多了少了、字段多了少了等等）。更多時還要自己寫處理方案來確保性能。還真的很久沒寫博客了這編的主要是體現(xiàn)個思想和不要人云亦云。
當前題目：C#、LINQ與ADO.NET主從表比對操作
鏈接地址：http://www.5511xx.com/article/dpcpgep.html
