ORM映射的弊端以及它对数据库优化影响

首先简单的介绍下ORM关系对象映射的概念。虽然NOSQL现在在迅速崛起，但大多数人仍然在使用稳定的关系型数据库，我们将数据组织成记录存储在关系数据库中，每一行代表一条记录。现代编程中，面向对象技术应用已经非常广泛，关系型数据库的数据组织形式与面向对象的数据组织形式存在根本上的差异。ORM的任务就是将关系型数据库中的数据通过ORM层映射为对象，使之能够应用于面向对象程序，方便编程。

它确实为大多数程序员提供了便利：

1、程序员不需要再动手写SQL语句，或者说大部分情况下不需要动手写，只需要调用一系列函数即可完成数据库CURD操作。

2、对不同数据库管理系统的连接以及操作进行了抽象，程序员完全可以不考虑使用的是什么数据库以及数据库的版本。

总之，在中小型的项目开发中，它的确为我们带来了高效的开发效率。

以上即是它的优点，下面进入正题，即ORM的弊端以及它对数据库优化的影响。

缺点：

1、对于复杂的SQL有心无力。

2.、无法完全屏蔽数据库底层细节（这也将是下面讨论的），开发人员仍然要熟悉数据库底层操作。

3、关系-对象映射的实现是以性能为代价，方便了开发，牺牲了效率。

4、多余的工作：大多数ORM框架为了达到屏蔽某些细节问题或者对数据库进行抽象，做了很多额外的工作，而这些工作对于大多数人来说是不需要的。比如，TP的ORM为防止SQL注入，做了很多类似强制类型转换的工作。这样做不仅仅降低了性能，同时也改变了数据本身的意义，对数据造成了污染。

ORM对数据库优化的影响。

ORM由于其屏蔽了数据库的CURD细节，程序员大多数情况下不需要再编写SQL语句，在一个小型的网站中，这样基本是没有什么问题的。即使效率低下，如今的硬件水平也可以弥补软件本身的性能问题。但如果在大型项目中盲目的使用ORM，定会造成性能的低下。原因如下：

1、上面关于ORM缺点已经提到了关于性能的两点问题。

2、数据库优化问题。

我将会重点解释数据库优化这个影响。

大型项目中，数据库关系、索引结构等都是经过严格控制的。程序员编写的SQL语句直接影响到数据库的执行效率（通过影响SQL执行计划），有经验的程序员可以自己动手写出高效的SQL语句，但毫无经验的程序员可能会使用ORM调用先关函数执行数据库操作，或许他能够获得好的执行计划，但我们不能将效率交给上帝来决定。

问题出现了， 根据上面的说法，我们是否需要完全自己动手写出SQL语句呢？我觉得在性能要求较高的情景中，应该是这样的。ORM虽然屏蔽了SQL语句，提高了开发效率，同样的，它也屏蔽了SQL优化的细节。

如果大部分的SQL语句是自己动手写出来的，这时候ORM框架本身也不在有什么值得我们依赖的优势了。我们既然要自己动手写出SQL语句，那么就可以自己动手写出关系-对象映射的简单框架。同样可以实现关系型数据库与面向对象编程的连接。

以上均是始终不够的胡诌八扯，要是哪里说错的，还请指正。