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

Estoy empezando a involucrarme en un proyecto de código abierto Gramps que está explorando cambiar su backend de BSDDB a una base de datos relacional. Ya sea en SQLite o en MySQL, no lo hemos decidido por completo e incluso podemos intentar hacer ambas cosas de forma 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 encargado investigar las capas de abstracción de DB. Actualmente hay una discusión wiki para compararlos. Un mapeador relacional de objetos podría ser bueno pero no es absolutamente necesario. aunque sé que suele ser sinónimo de una DB Abstraction Layer. Si se incluye un ORM, las consultas de anuncios deben estar disponibles sin mucha lucha.

En este momento la lista incluye:

CouchDB Todavía no he investigado esto.

DB-API parece ser una API estándar de python y cada db crea su propio módulo que lo utiliza. 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 los pitones.

SQLObject todavía no he investigado esto.

Entonces, ¿cuáles son las opiniones y sugerencias de los usuarios sobre las capas de abstracción de bases de datos para python?

Mira muy de cerca a SQLAlchemy.

Puedes probar y desarrollar con SQLite.

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

El DB-API, aunque está ampliamente adherido, tiene suficiente flexibilidad para que (1) no esté aislado de la variación de SQL en el RDBMS subyacente y (2) todavía hay características específicas del controlador de DB que son difíciles de ocultar.

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 rest del marco web de Django.

Use 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 debe estar en segundo lugar después del modelo de objeto. SQLAlchemy hace esto un enfoque razonable.

Una “Capa de abstracción DB” ocurrirá en el curso normal de los eventos. De hecho, debido a la DB-API (como la utiliza SQLAlchemy), se le dieron dos capas de abstracción: ORM y DB-API.

El acceso a una base de datos adecuada desde Python casi siempre se realiza mediante un módulo adaptador compatible con DB-API 2.0. Si bien todos los módulos de DB-API tienen API idénticas (o muy similares; no todos los backends son compatibles con todas las funciones), si escribe el SQL usted mismo, es probable que escriba SQL en un dialecto específico del producto, por lo que no son tan intercambiables. Practica 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 quieres un ORM como SQLAlchemy depende completamente de ti; Hay buenos argumentos de cualquier manera. Personalmente, no me gustan los ORM, pero luego tengo una licenciatura en matemáticas, por lo que el hecho de que aprecie el SQL como lenguaje probablemente no sea demasiado sorprendente 🙂

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

Cualquier ORM como SQLAlchemy, SQLObject o Django ORM se implementa sobre DB-API y recomiendo usar cualquiera de estos sobre DB-API directo porque puede dar a Gramps la flexibilidad de ejecutar sqlite en modo integrado para usuarios de escritorio locales y luego También comparta, en algún momento, una conexión de base de datos Postgresql / MySQL con una versión web de Gramps.

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 su uso en proyectos canónicos como Launchpad, y recientemente se ha 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.

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

Si su proyecto alguna vez tendrá una complejidad real, manténgase alejado de los ORM.

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

Cuando comencé a convertir una aplicación heredada para usar un ORM, busqué en SQLObject y SQLAlchemy. Al principio fui con SQLObject porque parecía familiar (la experiencia pasada de Django) y SQLAlchemy parecía complicado. Después de aproximadamente 2 horas comencé a golpear paredes con SQLObject. Luego miré a SQLAlchemy de nuevo y fui recompensado al instante. No solo entendía y mapeaba cada tabla extraña en la base de datos, sino que también podía hacer las búsquedas aún más extrañas que tenía que hacer más tarde.

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

Características útiles de CouchDB para Gramps: