python ORM(Flask-SQLAlchemy 介绍)

ORM 对象关系映射(Object Relational Mapping,简称ORM)

一个 ORM , 它的一端连着 Database, 一端连着 Python DataObject 对象。有了 ORM,可以通过对 Python 对象的操作,实现对数据库的操作,不需要直接写 SQL 语句。ORM 会自动将 Python 代码转换成对应的 SQL 语句。其余的操作,包括数据检查,生成 SQL 语句、事务控制、回滚等交由 ORM 框架来完成。

ORM 还是可以执行原始的 SQL 语句,以便执行一些复杂的/特别的操作。

 

ORM 类似标准的数据库接口,但很多工作由 ORM 代为处理了,不需要直接使用接口。

Python 的 ORM 模块:SQLAlchemy 等。

Flask-SQLAlchemy 是一个 Flask 扩展,简化了在 Flask 程序中使用 SQLAlchemy 的操作。
SQLAlchemy 是一个很强大的关系型数据库框架,支持多种数据库后台。SQLAlchemy 提
供了高层 ORM,也提供了使用数据库原生 SQL 的低层功能。

如何选择
你要考虑以下几个因素。

易用性 
如果直接比较API和ORM,显然后者取胜。对象关系映射(Object-Relational Mapper,ORM)在用户不知觉的情况下把高层的面向对象操作转换成低层的数据库指令。


性能
ORM 把对象业务转换成数据库业务会有一定的损耗。大多数情况下, 这种性能的降低微不足道,但也不一定都是如此。一般情况下,ORM 对生产率的提升远远超过了这一丁点儿的性能降低,所以性能降低这个理由不足以说服用户完全放弃 ORM。真正的关键点在于如何选择一个能直接操作低层数据库的抽象层,以防特定的操作需要直接使用数据库原生指令优化。


可移植性
选择数据库时,必须考虑其是否能在你的开发平台和生产平台中使用。例如,如果你打算利用云平台托管程序,就要知道这个云服务提供了哪些数据库可供选择。可移植性还针对 ORM。尽管有些 ORM 只为一种数据库引擎提供抽象层,但其他 ORM 可能做了更高层的抽象,它们支持不同的数据库引擎,而且都使用相同的面向对象接口。SQLAlchemy ORM 就是一个很好的例子,它支持很多关系型数据库引擎,包 括流行的 MySQL、Postgres 和 SQLite。


FLask集成度
选择框架时,你不一定非得选择已经集成了 Flask 的框架,但选择这些框架可以节省你编写集成代码的时间。使用集成了 Flask 的框架可以简化配置和操作,所以专门为 Flask 开发的扩展是你的首选。

 

Django 的ORM

ORM,全拼 Object- Relation Mapping,意为对象-关系映射实现了数据模型与数据库的解耦,通过简单的配置就可以轻松更换数据库,而不需要修改代码只需要面向对象编程,orm操作本质上会根据对接的数据库引擎,翻译成对应的sql语句,所有使用 Django开发的项目无需关心程序底层使用的是 MySQL、 Oraclesqlite……,如果数据库迁移,只需要更换 Django的数据库引擎即可关系型数拥库  中,根据横型类

python ORM(Flask-SQLAlchemy 介绍)_第1张图片

 

Django 和 SQLAlchemy 之间比较

活动记录 vs 数据映射

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 查询优化器,这可能是最简单优化任何查询的方法。

总结

orm 是活动记录实现的,数据库中每一行都直接映射到代码中的对象,不需要为了在代码中使用属性而预先定义架构,也可以只保存记录到数据库,因为它也映射到表中的特定行。Django 适用于所有常规 CRUD 操作。会自动生成主键,会自动提交等。Django Model 更简洁一些。例如对于类关联,Django 只要直接声明外键,就自动产生关联对象,而 SQLAlcyhemy 要定义外键、relationship 对象,如果有多个外键还要自己指定 join 规则……

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

 

你可能感兴趣的:(python,数据库,Python)