¿Cuáles son las capas de abstracción de bases de datos viables para Python?

Question

Estoy empezando a involucrarme en un proyecto de código abierto Gramps que explora el cambio de su back-end de BSDDB a una base de datos relacional. O bien SQLite o MySQL no hemos decidido completamente e incluso podemos intentar hacer ambos en alguna capacidad limitada. Soy un desarrollador profesional pero soy nuevo en Python, así que no estoy tan familiarizado con la selección actual de herramientas/bibliotecas. Me han encomendado la tarea de investigar las capas de abstracción DB. There is currently a wiki discussion going on to compare them. Un mapeador relacional de objetos puede ser bueno, pero no es absolutamente necesario. aunque sé que generalmente es sinónimo de una capa de abstracción DB. Si se incluye un ORM, las consultas de huecos deben estar disponibles sin mucha lucha.

En este momento la lista incluye:

CouchDB todavía no he mirado en esto.

DB-API esto parece ser una api de python estándar y cada db crea su propio módulo que lo usa. Incluso BSDDB parece tener uno escrito pero no lo he explorado completamente. son los módulos intercambiables?

SQLAlchemy Este parece ser el más popular en este momento? pero tengo una exposición muy limitada al mundo de las pitones.

SQLObject Todavía no he investigado esto.

¿Cuáles son las opiniones y sugerencias de las personas sobre las capas de abstracción de la base de datos para python?

Answer 1

Mire muy de cerca SQLAlchemy.

Puede probar y desarrollar con SQLite.

Puede entrar en producción con MySQL, sin hacer prácticamente ningún cambio en sus aplicaciones.

La API DB, aunque ampliamente adherida, tiene suficiente flexibilidad para (1) no estar aislado de la variación de SQL en el RDBMS subyacente y (2) todavía hay características específicas del controlador de BD que son difíciles de esconder.

Otra buena capa de ORM es el ORM que forma parte de Django. Puede (con un poco de esfuerzo) usar solo el ORM de Django sin usar el resto del marco web de Django.

Utilice una capa ORM (SQLAlchemy o SQLObject) en lugar de DB-API.

¿Por qué? Su modelo debe ser un modelo OO sólido, claro y bien pensado. El mapeo relacional debería ser el segundo después del modelo de objetos. SQLAlchemy lo hace un enfoque razonable.

Una "Capa de abstracción de DB" sucederá en el curso normal de los eventos. De hecho, debido a DB-API (como lo usa SQLAlchemy) usted dio dos capas de abstracción: ORM y DB-API.

Answer 2

Acceder a una base de datos adecuada desde Python casi siempre se hace usando un módulo adaptador DB-API 2.0. Si bien todos los módulos DB-API tienen API idénticas (o muy similares, no todos los servidores respaldan todas las características), si está escribiendo el SQL usted mismo, probablemente estará escribiendo SQL en un dialecto específico del producto, para que no sean tan intercambiables en practicar como son en teoría.

Honestamente, SQLite suena perfecto para su caso de uso.No me molestaría con "MySQL incrustado"; eso suena como lo peor de ambos mundos. Si usted quiere un ORM como SQLAlchemy es completamente suya; hay buenos argumentos de cualquier manera. Personalmente, me desagradan los ORM, pero luego tengo un título de matemática, por lo que el hecho de que aprecio SQL como lenguaje probablemente no sea demasiado sorprendente :)

Answer 3

CouchDB no es una base de datos relacional, por lo que no tiene una Interfaz DB-API. Es una base de datos documental que significa que no sería tan útil para Gramps porque requeriría algunas contorsiones para identificar enlaces entre personas relacionadas. Además de eso, solo se puede ejecutar en modo cliente/servidor.

Cualquier ORM como SQLAlchemy, SQLObject o Django ORM se implementan sobre DB-API y recomiendo usar cualquiera de estos sobre DB-API directa porque puede darle a Gramps la flexibilidad de ejecutar sqlite en modo incrustado para locales usuarios de escritorio y luego también compartan, en el futuro, una conexión de base de datos Postgresql/MySQL con una versión basada en web de Gramps.

Answer 4

Me gusta mucho Storm:

Storm es un mapeador objeto-relacional (ORM) para Python desarrollado en Canonical. El proyecto ha estado en desarrollo durante más de un año para el uso en proyectos Canonical como Launchpad, y ha sido recientemente lanzado como un producto de código abierto.

En mi opinión, Storm es mucho más fácil de aprender que SQLAlchemy. Es similar al ORM de Django.

Answer 5

Si su proyecto alguna vez tendrá alguna complejidad real, aléjese de los ORM.

http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx

Answer 6

cuando empecé a convertir una aplicación de legado de utilizar un ORM Miré en SQLObject y SQLAlchemy. Al principio fui con SQLObject porque me parecía familiar (pasada la experiencia de Django) y SQLAlchemy parecía complicado. Después de aproximadamente 2 horas, comencé a golpear las paredes con SQLObject. Luego miré a SQLAlchemy nuevamente y fui recompensado al instante. No solo entendió y cartografió cada tabla extraña en la base de datos, ¡incluso podría hacer las búsquedas más extrañas que tuve que hacer más tarde!

Answer 7

Creo que CouchDB sería la mejor opción para proyectos como Gramps.

características útiles para el abuelo CouchDB:

• ningún esquema, no hay migraciones.

• soporte para almacenar archivos directamente a la base de datos, por ejemplo, fotos de la familia, etc .: http://guide.couchdb.org/draft/api.html#attachments

• Ubuntu soporta CouchDB vía la mesa-sofá y se integra con Ubuntu One para compartir fácilmente o backuping: http://www.freedesktop.org/wiki/Specifications/desktopcouch

• se puede replicar fácilmente bases de datos couchdb, unirse a ellos a una gran base de datos, etc ...

• couchdb es muy flexible.

Answer 8

web2py tiene una capa de abstracción de base de datos que se puede utilizar de forma independiente.Cambiamos entre sqlite3, Microsoft SQL Server, Oracle y MySQL con cero cambios de código. Impresionado.