orm开发和纯sql开发对比
什么是ORM?
ORM，即Object-Relational Mapping（对象关系映射），它的作用是在关系型数据库和业务实体对象之间作一个映射，这样，我们在具体的操作业务对象的时候，就不需要再去和复杂的SQL语句打交道，只需简单的操作对象的属性和方法。
orm优点
首先，ORM最大的优势。不需要考虑sql
隐藏了数据访问细节，“封闭”的通用数据库交互，ORM的核心。他使得我们的通用数据库交互变得简单易行，并且完全不用考虑该死的SQL语句。快速开发，由此而来。
第二：ORM使我们构造固化数据结构变得简单易行。
在ORM年表的史前时代，我们需要将我们的对象模型转化为一条一条的SQL语句，通过直连或是DB helper在关系数据库构造我们的数据库体系。而现在，基本上所有的ORM框架都提供了通过对象模型构造关系数据库结构的功能。这，相当不错。
orm缺点：
第一：性能
无可避免的，自动化意味着映射和关联管理，代价是牺牲性能（早期，这是所有不喜欢ORM人的共同点）。现在的各种ORM框架都在尝试使用各种方法来减轻这块（LazyLoad，Cache），效果还是很显著的。
第二：增加学习成本.
面向对象的查询语言(X-QL)作为一种数据库与对象之间的过渡,虽然隐藏了数据层面的业务抽象,但并不能完全的屏蔽掉数据库层的设计,并且无疑将增加学习成本.
第三：复查sql难以控制
对于复杂查询，ORM仍然力不从心。虽然可以实现，但是不值的。视图可以解决大部分calculated column，case ，group，having,order by, exists，但是查询条件(a and b and not c and (d or d))。。。。。。
世上没有驴是不吃草的(又想好又想巧,买个老驴不吃草)，任何优势的背后都隐藏着缺点，这是不可避免的。
网友看法
纯sql更简洁
就我个人而言,我还是比较喜欢直接用 SQL 来进行查询, 我总觉得 ORM 还得熟悉它的各种查询条件,但是 ORM 对于后期切换数据库来说很方便,但是又有多少项目会切换数据库呢?
ORM 对于一些比较复杂的 sql 语句就更加难以控制.
但是如果你只是做一个很小的系统,请求量没有那么大的时候,我觉得使用 ORM 或者 SQL 应该都可以.
纯sql更灵活
使用SQL会更加灵活，限制条件不多，可以降低数据库范式等级来满足复杂多变的业务场景需求；但是ORM方式就必须严格遵守数据库强制外键的范式等级，理论上范式等级越高数据库使用越合理，实际情况并不是这样，范式的使用是需要特定业务场景的限制。
引入更多的使用条件限制和N+1的难题。以前有过项目尝试ORM强制外键关系，最后都是惨痛教训收场。当然ORM这种方案还是有一定优点，对象化操作多表数据，自动联动表关系处理，但是也带来了更多坏处，属于得不偿失的情况。
结论，建议放弃ORM的多表方案，降低数据库范式等级，不要使用强制外键，自己手动维护数据库表关系。但是必须在有清晰的数据库模型管理制度前提上。
我现在建表，不使用表之间的关联，什么外键约束，都不用，
对于我开发的一些应用程序，我一直在编写纯 SQL，主要用于 MySQL。 尽管我在 python 中使用过 ORM，例如 SQLAlchemy，但我并没有坚持使用它们太久。 通常是文档或复杂性（从我的角度来看）阻碍了我。我喜欢简洁
我是这样看的：使用 ORM 实现可移植性，如果它只是要使用一种类型的数据库，则使用纯 SQL。
纯sql门槛低
orm 写 sql 要学不少东西, 不如直接 sql 门槛低一点
但是纯sql会有注入的风险
sql 注入了解一下，用框架不一定是为了省事
不用 orm 但至少用 query builder 类的框架 至少不用担心 sql 注入之类的问题
有些语句复杂的 大部分 query builder 也支持用 raw sql
我个人比较喜欢纯 sql，因为比较好调试，好优化，适应性强，
