[Python-es] ORM de django vs SQLAlchemy

Chema Cortes pych3m4 en gmail.com
Mie Mar 17 22:15:53 CET 2010


El día 17 de marzo de 2010 15:39, Jose Caballero
<jcaballero.hep en gmail.com> escribió:

> El hecho de que django aún no de soporte estable a consultas multi-db es un
> dato importante en mi caso. Tengo que lidiar con 3 bases de datos distintas
> a la vez.
>
> La velocidad no es, de momento, un factor crucial.
>
> El otro factor que es importante para mí, y creo que ahí es donde se nota mi
> inexperiencia, es que necesito crear clases que incluyan no sólo el
> resultado de cada 'query' (por lo que asumo las clases serán en parte una
> réplica de mi 'schema') sino además mis propios métodos para hacer análisis
> estadístico con los resultados de los 'queries', etc. Aunque imagino que
> será igual de fácil en ambos casos, con una simple herencia de clases o
> similar.

Deberías haber empezado por lo que estabas buscando. SQLAlchemy está
llamado a convertirse en un estándar; pero si vas a trabajar con
django, no hay que pensar en nada más y usar lo que te ofrece django:
es rápido y lo hace muy bien. Si es necesario, puedes combinar ambos
ORM, siempre a costa de duplicar conexiones. Usa django ORM para el
control de sesiones y otras facilidades propias de la gestión web que
requieran diseños específicos de tablas, y usa alchemy para bases de
datos que estén ya creadas por otras aplicaciones con las que quieras
compartir diseño y código. Alchemy destaca por ser multibase, con
mejor soporte para un mayor número de SGDBs, con claves primarias y
externas multicolumna, joins reales, etc, etc. Y es muy robusto.

Para mí (opinión subjetiva) los ORMs no se pueden comparar
correctamente sin precisar qué base de datos vas a usar. Comparar ORMs
para luego usar sqlite como que no tiene mucho sentido.



Más información sobre la lista de distribución Python-es