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:

Adopted the easy-to-understand ActiveRecord patternA relatively small codebase

Cons:

Naming of methods and classes follow Java's camelCase styleDoes not support database sessions to isolate unit of work

Storm

Pros:

A clean and lightweight API leading to short learning curve and long-term maintainabilityDoes not need special class constructors, nor imperative base classes

Cons:

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

Django's ORM

Pros:

Easy-to-use with a short learning curveTightly integrated with Django to make it the de-factor standard when dealing with databases in Django

Cons:

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

peewee

Pros:

A Django-ish API; making it easy-to-useA lightweight implementation; making it easy to integrate with any web framework

Cons:

Does not support automatic schema migrationsMany-to-Many queries are not intuitive to write

SQLAlchemy

Pros:

Enterprise-level APIs; making the code robust and adaptableFlexible design; making it painless to write complex queries

Cons:

The Unit-of-work concept is not commonA heavyweight API; leading to a long learning curve

PonyORM

Pros:

A very convenient syntax for writing queriesAutomatic query optimizationSimplified setup and usage

Cons:

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.

转载于:https://www.cnblogs.com/tanxstar/p/6116549.html