Python有哪些可行的数据库抽象层

Question

我开始参与一个开源项目Gramps，该项目正在探索将其后端从BSDDB切换到关系数据库。无论是SQLite还是MySQL，我们都还没有完全决定，甚至可能会在有限的容量下尝试两者兼而有之。我是一个专业的开发人员，但我对python还不熟悉，所以我对当前选择的工具/库并不太熟悉。我的任务是研究数据库抽象层。There is currently a wiki discussion going on to compare them.对象关系映射器可能很好，但不是绝对必要的。尽管我知道这通常是DB抽象层的同义词。如果包含了ORM，那么就必须在不费吹灰之力的情况下提供广告查询。

现在的列表包括：

CouchDB 我还没调查过。

DB-API 这似乎是一个标准的python api，每个db都创建自己的模块来使用它。即使是BSDDB似乎也写了一篇文章，但我还没有完全研究过。这些模块可以互换吗？

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

SQLObject 我还没调查过。

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

Answer 1

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

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

Answer 2

从Python访问正确的数据库几乎总是使用符合DB-API 2.0的适配器模块来完成的。虽然所有的DB-API模块都有相同的API（或者非常相似；不是所有的后端都支持所有的特性），但是如果您自己编写SQL，那么您可能会用特定于产品的方言编写SQL，因此它们在实践中不如在理论上那样可互换。

老实说，SQLite听起来非常适合您的用例。我不介意使用“嵌入式MySQL”；这听起来是两个世界中最糟糕的。是否需要像SQLAlchemy这样的ORM完全取决于您；无论哪种方式都有很好的论据。就我个人而言，我不喜欢ORMs，但是我有一个数学学位，所以我喜欢SQL作为一种语言这一点可能并不奇怪：）

Answer 3

仔细观察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。