&引言
之前一直带的项目--廊坊一中考评系统在做1.0的时候,怎么都没有上线,这是我们的第一个版本,使用的框架可以说是很新的框架:
实体层:entity Framework
远程数据访问:WCF
前台:MVC
1.0之所以没有上线的原因其实很简单,前台页面相应太慢,后来,我们综合了很多方面,意识到了问题:数据访问层太慢。
&EntityFramework框架的优势体现在:
1、本身给我们编写好了映射代码,不需要我们去维护,每次数据库进行变更的时候,我们只需要更新或者添加表就可以了。
2、它不需要你创造大的数据访问层,D的代码都已经给我们生成好了。
3、它提供了LINQ查询数据库,这样我们不需要写SQL语句了。
&但是同样的它自身存在缺陷:
1、不支持大数据Bulk插入
2、不支持频繁的更新操作
3、同时,当我们的表不是严格按照凡是进行设计的时候,它就不能很好的支持映射了,这个时候我们只能自己手动维护。
4、EF的Context上下文不是线程安全的。
当考评系统开始的时候,大概每个老师大概要给300多个老师进行评分,这样我们一个老师就会有300条信息插入,一中300名教师,这样就是大概有上万条的数据进行插入。频繁的继续打开Context上下文获取一个单表,并关闭它,经过一段时间,就出现了内存泄露的情况。
&&如何避免EF不支持大数据Bulk插入?
内存泄露其实就是该内存空间使用完毕之后未回收,而为了避免这样情况我们要是保持Context一直打开的情况,其实这并不是最重要的,不要为wcf每一个请求创建一个Context对象,当数据量达到一个数量级的时候,我们才对数据进行提交就行了。
&&如何避免EF不支持频繁的更新操作?
这个是目前EF都没有办法避免的问题,这个时候,我们只能使用使用SQl语句进行扬长避短了。
&&数据库表的设计会不会影响我们的查询的速度?
我想说,并不影响,先前我认为,我们可以用字段表将多张表合并,后来,我发现,这样做并没有多大的意义,因为你的第一:基本的数据映射都已经为我们写好了,一张表和多张表并不需要我们手动维护;第二:多张表好维护,因为在交接的时候,我直接可以从表的名称上面判断出来这张表中存在哪些数据,如果我们用字段表就不好看出来了。
另外:我先前认为数据库表设计应该尽可能的严格按照第三范式来设计,这样,我们就更好进行维护。1.0版本就是按照这样的设计思路进行设计的,这样其实是很好的,但是2.0的时候,我尝试了打破第三范式的约束继续数据库表的设计,将本该作为数据的外键的属性字段,作为了表中的普通属性字段,这样业务逻辑就会简单很多,但是不利于扩展。
&结束语:
我们在数据库设计的时候,一定要考虑到那些功能是需要大数据访问的,我们在这些地方一定要考虑到逻辑的复杂性,以及数据库访问量的问题。如果逻辑太过复杂的时候,我们就需要考虑到重新设计数据库,如果这个数据库访问量大的话,我们就需要用SQl语句,并且,我们要考虑到数据量特别大的时候,需要用到线程和分布式等等。