Python’s SQLAlchemy vs Other ORMs[转发 7] 比较结论

Comparison Between Python ORMs

For each Python ORM presented in this article, we are going to list their pros and cons here:

SQLObject

Pros:

1. Adopted the easy-to-understand ActiveRecord pattern
2. A relatively small codebase

Cons:

1. Naming of methods and classes follow Java's camelCase style
2. Does not support database sessions to isolate unit of work

Storm

Pros:

1. A clean and lightweight API leading to short learning curve and long-term maintainability
2. Does not need special class constructors, nor imperative base classes

Cons:

1. Forcing the programmer to write manual table-creation DDL statements instead of automatically deriving it from the model class
2. Contributors of Storm have to give their contributions' copyrights to Canonical Ltd.

Django's ORM

Pros:

1. Easy-to-use with a short learning curve
2. Tightly integrated with Django to make it the de-factor standard when dealing with databases in Django

Cons:

1. Does not handle complex queries very well; forcing the developer to go back to raw SQL
2. Tightly integrated with Django; making it hard to use outside of a Django context

peewee

Pros:

1. A Django-ish API; making it easy-to-use
2. A lightweight implementation; making it easy to integrate with any web framework

Cons:

1. Does not support automatic schema migrations
2. Many-to-Many queries are not intuitive to write

SQLAlchemy

Pros:

1. Enterprise-level APIs; making the code robust and adaptable
2. Flexible design; making it painless to write complex queries

Cons:

1. The Unit-of-work concept is not common
2. A heavyweight API; leading to a long learning curve

PonyORM

Pros:

1. A very convenient syntax for writing queries
2. Automatic query optimization
3. Simplified setup and usage

Cons:

1. Not designed to process hundreds of thousands or millions of records simultaneously

Summary and Tips

Compared to other ORMs, SQLAlchemy stands out in its focus on the unit-of-work concept which is prevalent whenever you write SQLAlchemy code. The DBSession concept might be hard to understand and use correctly initially, but later you will appreciate the additional complexity which reduces accidental database commit-timing-related bugs to almost zero. Dealing with multiple databases in SQLAlchemy can be tricky since each DB session is confined to one database connection. However, this kind of limitation is actually a good thing since it forces you to think hard about the interaction between multiple databases and make it easier to debug database interaction code.

In the future articles, we are going to fully explore more advanced use cases of SQLAlchemy to truly grasp its immensely powerful APIs.