Python 可行的数据库抽象层是什么答案

【问题标题】：What are the viable database abstraction layers for PythonPython 可行的数据库抽象层是什么
【发布时间】：2010-10-15 08:30:18
【问题描述】：

我开始参与一个开源项目Gramps，该项目正在探索将他们的后端从 BSDDB 切换到关系数据库。无论是 SQLite 还是 MySQL，我们都还没有完全决定，甚至可能会在有限的能力范围内同时尝试两者。我是一名专业开发人员，但我是 python 新手，所以我对当前的工具/库选择不太熟悉。我的任务是研究数据库抽象层。 There is currently a wiki discussion going on to compare them. 对象关系映射器可能很好，但不是绝对必要的。虽然我知道这通常是数据库抽象层的同义词。如果包含 ORM，则必须提供即席查询，而无需费力。

目前列表包括：

CouchDB 我还没有研究这个。

DB-API 这似乎是一个标准的 python api，每个 db 创建自己的模块来使用它。甚至 BSDDB 似乎也写了一个，但我还没有完全探索它。模块可以互换吗？

SQLAlchemy 这似乎是现在最流行的？但我对 python 世界的了解非常有限。

SQLObject 我还没有研究这个。

那么人们对python的数据库抽象层有什么看法和建议？

【问题讨论】：

很好地回答了所有问题。我在gramps wiki上写了我的最终建议。 gramps-project.org/wiki/…

标签： python sql mysql database sqlite

【解决方案1】：

仔细观察 SQLAlchemy。

您可以使用 SQLite 进行测试和开发。

您可以使用 MySQL 进入生产环境 - 基本上不对您的应用程序进行任何更改。

虽然得到广泛遵守，但 DB-API 具有足够的灵活性，因此 (1) 您不会与底层 RDBMS 中的 SQL 变体隔离开来，并且 (2) 仍然存在难以隐藏的特定于 DB 驱动程序的功能.

另一个好的 ORM 层是作为 Django 一部分的 ORM。您可以（稍加努力）只使用 Django ORM 而无需使用 Django Web 框架的其余部分。

使用 ORM 层（SQLAlchemy 或 SQLObject）而不是 DB-API。

为什么？您的模型应该是一个坚实、清晰、经过深思熟虑的 OO 模型。关系映射应该排在对象模型之后。 SQLAlchemy 使这是一种合理的方法。

“数据库抽象层”将在正常的事件过程中发生。事实上，由于 DB-API（由 SQLAlchemy 使用），您提供了两个抽象层：ORM 和 DB-API。

【讨论】：

【解决方案2】：

从 Python 访问适当的数据库几乎总是使用符合 DB-API 2.0 的适配器模块来完成。虽然所有 DB-API 模块都具有相同的 API（或非常相似；并非所有后端都支持所有功能），但如果您自己编写 SQL，您可能会用特定于产品的方言编写 SQL，因此它们在按照理论上的做法进行实践。

老实说，SQLite 听起来非常适合您的用例。我不会为“嵌入式 MySQL”而烦恼；这听起来像是两全其美。是否需要像 SQLAlchemy 这样的 ORM 完全取决于您；无论哪种方式都有很好的论据。就个人而言，我不喜欢 ORM，但我有数学学位，所以我欣赏 SQL 作为一门语言这一事实可能并不令人惊讶:)

【讨论】：

好吧，显然我还不能投票，但我同意你关于喜欢 sql 的观点

【解决方案3】：

CouchDB 不是关系数据库，因此它没有 DB-API 接口。它是一个文档数据库，这意味着它对 Gramps 没有那么有用，因为它需要一些扭曲来识别相关人员之间的联系。除此之外，它只能在客户端/服务器模式下运行。

SQLAlchemy、SQLObject 或 Django ORM 等任何 ORM 都是在 DB-API 之上实现的，我建议在直接 DB-API 上使用其中任何一个，因为它可以让 Gramps 灵活地在本地桌面的嵌入式模式下运行 sqlite用户，然后还会在未来某个时候与基于 Web 的 Gramps 版本共享 Postgresql/MySQL 数据库连接。

【讨论】：

【解决方案4】：

我真的很喜欢Storm：

Storm 是一个对象关系映射器 (ORM) for Python 开发于典范。该项目已在经过一年多的发展在规范项目中使用，例如启动板，最近作为开源产品发布。

在我看来，Storm 比 SQLAlchemy 更容易学习。类似于 Django 的 ORM。

【讨论】：

感谢您的提醒。我检查过了，但就像你说的这些项目只有一年的历史。我最近因为选择了一个听起来很适合我的技术堆栈但不是这样的边缘技术而被烧毁，所以我更愿意推荐一些更主流的东西。

【解决方案5】：

web2py 有一个可以独立使用的数据库抽象层。我们在 sqlite3、Microsoft SQL Server、Oracle 和 MySQL 之间进行了零代码更改。印象深刻。

【讨论】：

【解决方案6】：

当我开始将旧版应用程序转换为使用 ORM 时，我研究了 SQLObject 和 SQLAlchemy。起初我选择 SQLObject，因为它看起来很熟悉（过去的 Django 经验）并且 SQLAlchemy 看起来很复杂。大约 2 小时后，我开始使用 SQLObject 碰壁。然后我再次查看 SQLAlchemy 并立即获得了回报。它不仅能理解和映射数据库中的每一个奇怪的表，它甚至可以做我以后必须做的更奇怪的查找！

【讨论】：

【解决方案7】：

我认为 CouchDB 将是 Gramps 等项目的最佳选择。

对 Gramps 有用的 CouchDB 功能：

无架构，无迁移。
支持将文件直接存入数据库，例如全家福等：http://guide.couchdb.org/draft/api.html#attachments
Ubuntu 通过 desktop-couch 支持 CouchDB，并与 Ubuntu One 集成，便于共享或备份：http://www.freedesktop.org/wiki/Specifications/desktopcouch
您可以轻松复制 couchdb 数据库，将它们加入一个大型数据库等...
couchDB 非常灵活。

【讨论】：

【解决方案8】：

如果您的项目有任何真正的复杂性，请远离 ORM。

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

【讨论】：

有趣的文章。强硬地说“这永远无法工作”（这显然是不真实的），但这是一个有趣的点列表。
我必须同意有趣但有点极端。因为我之前没有使用过真正的 orm，所以我无法确定它们可能会变得多么痛苦，但似乎人们喜欢它们并让它们发挥作用。
好吧，他有很好的证据证明他们为什么行不通。这是理解关系代数的失败。对象行。 ORM 是一种可怕的拐杖，它会教人懒惰并导致比 SQL 本身更复杂的问题。大多数人永远不必担心 ACID 合规性，所以 ORM 对他们来说没问题