卷2：第20篇 SQLAlchemy.pdfVIP

卷2 ：第20章 SQLAlchemy 作者：Michael Bayer 译者：谢路云 状态：翻译中 原⽂地址：http://www .aosabook .org/en/sqlalchemy .html SQLAlchem​​y是⼀个Python语⾔的数据库⼯具包和关系对 映射 ORM)系统，始于2005 年。从⼀开始，它就⼒求通过Python的数据库API （即DBAPI ）提供⼀种和关系数据 库交互的端对端系统。从早期的版本开始，SQLAlchemy的功能就吸引了很多⼈的注 意⼒。它的主要特性包括能够流畅的表达复杂的SQL查询和对 映射，以及实现 了Unit of Work 模式来⾼度⾃动化的完成数据在数据库中的持久化。 从⼀个渺⼩⽽粗糙的概念性实现开始，SQLAlchemy迅速经历了⼀系列蜕变和打磨。 随着⽤户群的增长，内部架构和公共API也在不断的迭代。到了2009年⼀⽉发布0 .5版 本之时，SQLAlchemy 已经在⼤量的⽣产环境中部署并证明了⾃⼰，并开始稳定下 来。0 .6 （20 10年四⽉）和0 .7 （20 11年五⽉）两个版本对架构和API的改进使我们成为 了最⾼效和最稳定的第三⽅库。截⾄撰写本⽂之时，⼤量不同领域的组织都在使⽤ SQLAlchem​​y 。它已经被⼤家认可并事实上成为使⽤Python操作关系型数据库的标准 库。 20.1.数据库抽象层的挑战 “数据库抽 层”通常指的是⼀种⽤来和数据库通讯并隐藏数据的存储和查询的⼤部分 细节的系统。对这个词的理解有时会⾛向⼀个极端，认为这样的系统应该隐藏的不仅 是所使⽤的关系数据库的细节，还应该包括数据的关系结构，甚⾄不再关⼼底层的存 储机制是否是基于关系的。 对于ORM最常见的批评认为以上就是这种⼯具的最主要⽬的——把关系数据库“藏起 来” ，接管和数据库的交互并将它们转化为实现的细节。这种⽅式的核⼼意义在于将 设计和查询关系数据结构的⼯作从开发者转移到⼀个不透明的第三⽅库中。 经常和关系数据库打交道的⼈都知道，这种认识完全是不切实际的。关系结构和SQL 查询都是功能性的，它们组成了⼀个应⽤程序设计的核⼼。应该如何在查询中设计、 组织和操作这些结构不仅取决于要查询哪些数据，也取决于数据的结构。如果连这些 信息都要隐藏起来，那么也就根本没有使关系数据库的必要了。 既要满⾜应⽤程序屏蔽底层关系数据库复杂性的期望，又要满⾜使⽤关系数据库所必 要的繁复，这种⽭盾被称为“对 -关系的阻抗不匹配” 问题。SQLAlchem​​y采⽤了⼀些 新颖的⽅法来解决这个问题。 SQLAlchemy​​ 的数据库抽 层 SQLAlchem​​y认为开发⼈员必须要考虑他或者她的数据的关系形式。预判并隐藏数据 库schema和查询的系统所设计的⾏为只会降低使⽤关系数据库的必要性，进⽽导致阻 抗不匹配所带来的⼀系列经典问题。*) 但同时，这些⾏为的实现应该也必须执⾏在⼀个尽可能⾼的层次上。将⼀个对 模型 和⼀个schema关联起来并通过SQL语句将对 持久化是⼀项重复性极⾼的任务。使⽤ ⼯具来将这些任务⾃动化才能开发出更加简洁、⾼效和强⼤的应⽤程序。⽽⼿动实现 这些操作的应⽤程序所需的开发时间将会是它的数倍。*) 因此，SQLAlchemy对⾃⼰的定位是⼀个⼯具包 ，这是为了强调开发者才是所有关系 结构以及这些结构和应⽤程序之间的联系的设计者和构造者，⽽不是第三⽅库的盲⽬ 使⽤者。通过开放“关系” ，SQLAlchem​​y实现的理念是“不完全抽 ” ，*)它不利开发 者在应⽤程序和关系数据库之间⾃定义⼀个⾃动化的交互层。SQLAlchem​​y的创新在 于它能够在不牺牲对关系数据库的控制能⼒的前提下做到⾼度的⾃动化。 20.2.两个世界：核⼼层 （Core ）与对象关系映射层 （ORM ） 为了达到⼯具包这个⽬标，SQLAlchem​​y将与数据库交互的每⼀层都开放成为了⼀组 成熟的API ，这产⽣了两种主要的交互⽅式，分别是核⼼层 （Core ）和对 关系映射 层 （ORM ）。核⼼层负责和Python的数据库API （DBAPI ）的交互、拼接数据库能够 理解的SQL语句并管理schema 。这些功能都对应着公开的API 。 图20 .1的SQLAlchem​​y的层图 核⼼/ ORM SQLAlchem​​y的分离⼀直是最本质的特征，它既有优点和缺点。⽬前在 SQLAlchem​​y的明确的