数据库设计

浅谈ORM

我是搞C#的菜鸟(别喷)，只接触过EF和SqlSugar,正在作的项目用到的就是国产的SqlSugar，我的感受写法还能够。如今的开发基本上不多还有写原生sql的了，由于ORM框架不只能提升开发效率，并且还能支持各类数据库，避免了原生sql在更换数据库时的尴尬。可是说白了ORM框架最终也是将object转换成sql语句，不过感受他应该不会给你优化sql吧。当遇到一些复杂查询的时候，好比多个表关联、各类子查询混在一块儿的时候，框架就显得有点乏力，感受很死板。

在程序方面，就拿C#来讲吧，当查询少许数据时，ORM框架确定是没问题，方便高效。若是操做的数据量过大，那确定会有一些弊端，相对于ADO来讲仍是显得比较死板，没有原生sql灵活，可以适应各类复杂多变的场景。在查询时要合理利用内存，该缓存的缓存，不要把全部的数据读到内存再作业务处理，而应该是动态的边读边处理。

总而言之，言而总之，这是我在项目中使用ORM框架时的一点理解。不过如今作的项目通常不可能在去拼写sql了，可是我仍是以为仍是应该了解一些sql方面的优化。

1、表设计

一、在设计字段类型时，若是某个字段只包含数字，尽可能就设计为数值类型，不要设计成字符类型，不然会影响查询和链接的性能。

二、尽可能使用varchar或nvarchar代替char和nchar，由于varchar和nvarchar类型长，存储空间小，能够节省存储空间，并且对于查询来讲，在一个存储空间相对较小的字段内搜索效率要高一些。

三、在数据量不是很大，使用触发器或自定义函数时，最好是使用表变量，若是是数据量较大可使用临时表。由于临时表是利用了硬盘，而表变量是占用了内存，所以小数据量固然是内存中的表变量更快。并且在存储过程当中，使用表变量与使用临时表相比，减小了存储过程的从新编译量；若是使用到了临时表，在存储过程的最后务必将全部的临时表显式删除，先 truncate table ，而后 drop table ，这样能够避免系统表的较长时间锁定。

2、索引

一、在查询时，为了不全表扫描，应该首先应考虑在 where 及 order by 涉及的列上创建索引。

二、不是全部的索引都是有用的，当索引列有大量数据重复时，查询可能不会去利用索引，也就提升不了查询效率。

三、索引并非越多越好，索引在提升查询效率的同时也下降了插入(insert)和更新(update)的效率，因此在建索引时要慎重考虑，不要放在常常更新的字段上，一张表的索引最好不要超过6个。

3、SQL语句查询

一、在程序中最好是不要使用select * from t；select count() from t，用具体的字段名代替“”，这样能够减小数据负担。若是是多表关联查询，不一样的表存在相同名称的字段，也会形成混淆。但若是是在后台数据库作临时查询，特别是对表字段不熟悉的时候，用select * 就比较方便了。

二、用exists和not exists代替in和not in，由于in 是把外表和内表做hash 链接，而exists是对外表做loop循环，每次loop循环再对内表进行查询，并且IN不对NULL进行处理，exists会对NULL值进行处理。

三、查询时，在where字句中使用!=、<>、or、in、not in、like以及对字段进行表达式操做或函数操做时，都是进行全表扫描，虽然有些时候没办法避免，可是能换其余方式的，最好不要作全表扫描。

四、不要在 where 子句中的“=”左边进行函数、算术运算或其余表达式运算，不然系统将可能没法正确使用索引。

五、后台尽可能不要向前台返回大数据量，若是数据量过大，更应该注意sql优化，不要返回一些不须要的列，或者也该考虑考虑需求是否合理了。并且尽可能避免大事务操做，提升系统的并发能力。