El día 17 de marzo de 2010 15:39, Jose Caballero <jcaballero....@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. _______________________________________________ Python-es mailing list Python-es@python.org http://mail.python.org/mailman/listinfo/python-es FAQ: http://python-es-faq.wikidot.com/