上传的数据可能存在版本不一致，基础信息都不会有变化但扩展的表或字段会不存在，原因是客户端存在没有升级的情况。
系统从Access数据库文件中取数据，使用整合后把相关数据并统计后对数据进行入库到系统数据库。部分的字段不能直接入库需要进行转换处理。由于数据库数据在进行操作时已经不会产生任何的变化。可以把数据都预先读取到内存当中。从而产生数据临时存放容器选择为IList和DataTable选择。
表A为主表：外表操作以表A为切入口, 根据表1 的某人字段从而选择当前记录行的子信息来源，关联字段要用到两个字段才能***。主表对从表的关系为：一对多的关系
表B为从表1：
表C为从表2：
把数据源转成实体操作
好处：操作直观，操作的字段不用每次比较时都进行比较。
缺点：性能不高。一个月的数据上百条记录用时几秒，一年的数据上几千条记录统计整理用时5分钟。数据量越多性能越明显。
ADO.NET
直接把表数据都查询出来没有任何过滤条件。在进行从表查询时不进行对实际的数据库文件进行操作。
好处：通过主表查询从表的记录信息在性能消耗并不高。同一文件一个月数据用时1秒之内，一年数据10秒之内。
缺点：操作并不直观，每次比较都要进行强制转换格式。后期有业务规则变化不好处理。
采用支持关联查询的ORM框架
好处：不用处理再次查询的操作，而且能用实体操作更为直观。
缺点：市面上没有支持Access的ORM框架，而且一般流行的ORM框架都以配置文件使用。不方便动态变化的上传文件名。
现在项目处理方案：
由于方案三先使用起来比较麻烦要自己好写底层类。Ado.net做操作查询然后转为实体进行统计。发现真实使用时和直接采用方案二的时间一样。原因可能是从表查询才是性能的主要瓶颈，转为实体不是并不是什么性能问题。
如果采用方案三的方式又可以在查询DataTable这个处提高更多的性能。并且减少浪费内存资源不像现有方案用了同一数据占用了两份资源。
备注：为什么没有真实的数据报告。主要当时没有想到要写这篇文档，就没有把当时使用的数据保留下来。不能一味听到别人说那个好那个不好那跟着别人走更多的时候是要有实践。个人觉得现在的ORM框架是很好用很方便逻辑和代码的处理，但遇到现实中的情况就有点力不从心（如表多了少了、字段多了少了等等）。更多时还要自己写处理方案来确保性能。还真的很久没写博客了这编的主要是体现个思想和不要人云亦云。
原文链接：http://www.cnblogs.com/16659716/archive/2012/05/10/2493975.html
【编辑推荐】
