Django的ORM vs Flask的SQLAlchemy

ORM的简介

• ORM代表对象关系映射（Object Ralational Mapping）。

1. 对象：这部分代表使用框架的对象和编程语言。（例如Python）
2. 关系：这部分使用的RADBMS关系型数据库，大多数关系型数据库之间的的共同点是它们的关系结构（表、列、键、约束等）。
3. 映射：这部分表示对象和数据表之间的桥梁和链接

ORM是为了将编程语言与数据库之间相连，以便简化创建依赖与数据的应用程序过程

Django 和 SQLAlchemy 之间比较

一、 活动记录VS数据映射

• Django ORM 采用活动记录实现---大多数ORM中能看到这种实现。也就是说数据库中每一行都直接映射到代码中对象。ORM框架不需要为了在代码中使用属性而预先定义框架，只需要使用他们，因为框架可以通过查询数据库架构“理解”结构。所有只保存记录到数据库。它映射到表中的特定行。

• SQLAlchemy 采用数据映射实现—当使用这种方式实现，数据库结构和对象结构之间存在间隙（它们不像活动记录的实现）。大多数情况下，必须使用另外的持久层来保持与数据库的交互。

  例如保存对象

  db.session.add(news)
  db.session.commit()

  因此当采用活动记录实现的时候不能只调用save方法，但是在另一方面，代码不需要知道数据库中整个关系结构的允许，因为代码和数据库之间没有直接关系

• 总结：两者之间谁会获胜？

  1. 应用程序大多数CURD(创建、读取、更新、删除)程序，而在不同数据实体之间没有使用困难且复杂规则，那么应该采用活动记录实现(Django)。它将帮助轻松地快速产品设置MVP最简化可实行产品（Minimum Viable Product）。
  2. 如果有许多业务规则和限制条件，最好采用数据映射模型，因为它不会捆绑并强迫严格遵循活动记录来考量

二、使用复杂查询

• 在某些情况下，Django和SQLAlchemy可以同时使用，现实环境中，主要实例Django用于所有的CURD操作，而SQLAlchemy用于更复杂的查询，通常是只读查询。

三、主键自动生成

• 两个框架之间的另一个不同是Django 能为表自动创建主键。SQLAlchemy却做不到，必须手段为每张表创建主键。

四、自动提交

• 默认情况下，Django会自动提交，SQLAlchemy却不行。自动提价会影响使用框架的方式（事务、回滚）

五、性能

• 我认为只在这里写（X 比 Y 快）是不负责任的。由于 ORM 具有如此多特征和功能，并且它们在每个框架中也不同，这将很难得出结论。根据我的经验，使用框架特性的方式，会对应用程序中数据层的整体性能产生极大影响。因此我建议不要通过性能来选择框架，而是应该学习如何合理利用框架。

  假如在 ORM 框架中使用原始的 SQL 查询、使用 Jooq 或者只是部分查询不使用 ORM，可以了解 EverSQL 查询优化器，这可能是最简单优化任何查询的方法。

总结

1. ORM是活动记录实现的，数据库中每一行都直接映射到代码中的对象，不需要为了在代码中使用属性而预先定义架构，也可以只保存记录数据库，因为它映射到表中的特定行。Django适用于所有的常规CURD操作。会自动生成主键，会自动提交等。Django Model更简洁一些。

   例如：对于类关联，Django只要声明外键，就会自动产生关联对象，而SQLAlchemy要定义外键、Relationship对象，如果有多个外键还要定义自己的Join规则

2. SQLAlchemy是数据库映射实现，数据库结构和对象结构之间存在间隙，必须使用另外的持久层于数据库的交互（例如保存对象），不会捆绑并强迫严格遵循活动记录来考量。适用于复杂查询。