在介绍 Python 的 ORM 框架（Django 和 SQLAlchemy）不同之前，我们先要确保完全理解 ORM 框架的用途。
ORM 代表对象关系映射（Object Relational Mapping）。让我们依次看看这三个单词，它们正好解释了 ORM在真实环境中的用处:
● 对象 – 这部分表示使用框架的对象和编程语言，例如 Python。
● 关系 – 这部分表示正在使用的 RDBMS (关系数据库管理系统)数据库。其中包括许多流行的关系数据库，而你可能正在使用以下数据库 — MSSQL、MySQL、Oracle数据库、PostgreSQL、MariaDB、PerconaDB、TokuDB。大多数关系数据库之间的共同点是它们的关系结构(表、列，键、约束等)。
● 映射 – 最后这部分表示前两部分对象和数据表之间的桥梁和连接。
因此可以得出的结论是 ORM 是为了将编程语言与数据库之间相连，以便简化创建依赖于数据的应用程序过程。
Django ORM 采用活动记录实现 — 大多数 ORM 中能看到这种实现。基本上也可以说是数据库中每一行都直接映射到代码中的对象，反之亦然。ORM 框架（如 Django） 不需要为了在代码中使用属性而预先定义架构，只需要使用它们，因为框架可以通过查看数据库架构“理解”结构。此外，也可以只保存记录到数据库，因为它也映射到表中的特定行。
SQLAlchemy 采用数据映射实现 — 当使用这种方式实现时，数据库结构和对象结构之间存在间隙（它们不像活动记录的实现是 1:1）。大多数情况下，必须使用另外的持久层来保持与数据库的交互（例如保存对象）。因此当采用活动记录实现的时候不能只调用 save() 方法（反对观点），但另一方面，代码不需要知道数据库中整个关系结构的运行，因为代码和数据库之间没有直接关系。
那么它们之间谁获胜了呢？都没有。这取决于你要实现什么。我相信如果你的应用程序大多是 CRUD (创建、读取、更新、删除)程序，而在不同数据实体之间没有使用困难且复杂规则，那么应该采用活动记录实现(Django)。它将帮助你轻松快速地为产品设置 MVP，而不会有任何困难。如果有许多“业务规则”和限制条件，最好采用数据映射模型，因为它不会捆绑并强迫严格遵照活动记录来考量。
在某些情况下，Django 和 SQLAlchemy 可以同时使用。现实环境中我多次见到主用例是 Django 用于所有常规 CRUD 操作，而 SQLAlchemy 用于更复杂的查询，通常是只读查询。
有关这方面更多的信息和实例，可以看看 BetterWorks 工程博客(我们没有任何联系，但不管怎样，我们喜欢他们的博客)。
两个框架之间的另一个不同是 Django 能为表自动创建主键, SQLAlchemy 却做不到。必须手动为每张表创建主键。权衡利弊 — 你认为哪种框架最清楚符合表的主键？根据团队的知识和经验，可以自行决定。
默认情况下，Django 会自动提交， SQLAlchemy 却不行。自动提交会影响使用框架的方式（事务、回滚等）。
Django 和 SQLAlchemy 都能用于 MySQL、PostgreSQL、Oracle 和 SQLite。如果你正在使用 MSSQL，则应该使用 SQLAlchemy，因为它完全支持 MSSQL ，并且也可以找到更多相关的信息和文档。
在网上有一个普遍的观点，认为 Django 更容易学习。这是显而易见的，由于它通常都用在没有特别复杂的用例上。因此，应该考虑愿意投入多少精力来学习框架，与 SQLAlchemy 交叉学习以便获得更多的灵活性（假使你真的需要它）。
毫无疑问，在 Python ORM 框架中 SQLAlchemy 拥有最大的社区。如果社区对你至关重要（我认为它应该是），SQLAlchemy 该是你的选择。这并不说明对于其它框架，你不能找到任何帮助，例如 Django。你也可以获得 bug 修复，从 StackOverflow 得到问题的答案和其它需要的帮助，但概率仅仅比 SQLAlchemy 高。
我认为只在这里写（X 比 Y 快）是不负责任的。由于 ORM 具有如此多特征和功能，并且它们在每个框架中也不同，这将很难得出结论。根据我的经验，使用框架特性的方式，会对应用程序中数据层的整体性能产生极大影响。因此我建议不要通过性能来选择框架，而是应该学习如何合理利用框架。
假如在 ORM 框架中使用原始的 SQL 查询、使用 Jooq 或者只是部分查询不使用 ORM，可以了解 EverSQL 查询优化器，这可能是最简单优化任何查询的方法。
任何比较中，我认为最好把决策权交还给读者。每个用例之间是不同的，不同的技术也可以更适用。看看上面指出的差异，让我们知道你做出了什么决定。
评论