¿Cuáles son las limitaciones del ORM de Django?

Question

He oído a desarrolladores que no quieren usar ORM, pero no saben por qué. ¿Cuáles son las deficiencias del ORM?

Answer 1

Permítanme comenzar diciendo que defiendo plenamente el uso del ORM para la mayoría de los casos simples. Ofrece una gran comodidad cuando se trabaja con un modelo de datos muy directo (relacional).

Pero, ya que preguntas por las deficiencias ...

Desde un punto de vista conceptual, un ORM nunca puede ser una representación efectiva del modelo de datos subyacente. En el mejor de los casos, será una aproximación de sus datos, y la mayoría de las veces, esto es suficiente.

El problema es que un ORM asignará una base de "una clase -> una tabla", lo que no siempre funciona.

Si tiene un modelo de datos muy complejo, que, idealmente, no puede ser representado adecuadamente por una única tabla de base de datos, entonces puede pasar mucho tiempo luchando contra el ORM, en lugar de tener que funcionar para tú.

En un nivel práctico, encontrará que siempre hay una solución; algunos desarrolladores serán partidistas en su apoyo a favor/en contra de un ORM, pero yo estoy a favor de un enfoque híbrido. El Django funciona bien para esto, ya que puede ingresar fácilmente en SQL sin formato según sea necesario. Algo así como:

Model.objects.raw("SELECT ...") 

ORM tomar una gran parte del trabajo fuera del 99,99% de los otros casos, cuando se está realizando operaciones CRUD simples en contra de sus datos.

En mi experiencia, los dos mejores razones para evitar un ORM por completo son:

• Cuando se tiene datos complejos que se recupera con frecuencia a través de varias combinaciones y agregaciones. A menudo, escribir el SQL a mano será más claro.
• Rendimiento. Los ORM son bastante buenos para construir consultas optimizadas, pero nada puede competir con la escritura de una pieza de SQL agradable y eficiente.

Pero, cuando todo está dicho y hecho, después de trabajar extensamente con Django, puedo contar con una mano el número de ocasiones en que el ORM no me ha permitido hacer lo que quiero.

Answer 2

Uno de los mayores problemas que se le ocurren es que la herencia de edificios en Django ORM es difícil. Básicamente, esto se debe al hecho de que las capas ORM (Django) están tratando de cerrar la brecha siendo ambos & OO relacionales. Otra cosa es, por supuesto, múltiples claves externas de campo.

Una carga nivelada en Django ORM es que abstraen tanto del motor de base de datos que escribir aplicaciones eficientes y escalables con ellos es imposible. Para algunos tipos de aplicaciones, aquellas con millones de accesos y modelos altamente interrelacionados, esta afirmación es a menudo cierta.

La gran mayoría de las aplicaciones Web nunca llegan a un público tan grande y no alcanzan ese nivel de complejidad. Los ORM de Django están diseñados para lanzar proyectos rápidamente y ayudar a los desarrolladores a saltar a proyectos basados ​​en bases de datos sin requerir un profundo conocimiento de SQL. A medida que su sitio web crezca y sea más popular, seguramente deberá auditar el rendimiento como se describe en la primera sección de este artículo. Eventualmente, es posible que tenga que comenzar a reemplazar el código ORM-driven con SQL sin formato o procedimientos almacenados (lea SQLAlchemy, etc.).

Afortunadamente, las capacidades de los ORM de Django continúan evolucionando. La biblioteca de agregación de Django V1.1 es un avance importante, lo que permite una generación eficiente de consultas a la vez que proporciona una sintaxis familiar orientada a objetos. Para una mayor flexibilidad, los desarrolladores de Python también deberían mirar SQLAlchemy, especialmente para las aplicaciones web de Python que no dependen de Django.

Answer 3

creator of SQLAlchemy's response to the question is django considered now pythonic.. Esto muestra una gran diferencia y una profunda comprensión del sistema.

sqlalchemy_vs_django_db discussion in reddit

Nota: Tanto los enlaces son bastante larga, tendrá tiempo para leer. No estoy escribiendo la esencia de ellos, lo que puede llevar a malentendidos.

Answer 4

Existen varios problemas que parecen surgir con cada sistema de Asignación de relacional de objetos, sobre el cual creo que el artículo clásico es de Ted Neward, quien describió el tema como "The Vietnam of Computer Science". (También hay una followup in response to comments on that post y algunos comentarios de propio Jeff Atwood here de desbordamiento de pila.)

Además, un simple problema práctico con los sistemas de ORM es que hacen que sea difícil ver cómo muchas consultas (y que consultas) son en realidad se está ejecutando por un bit dado de código, lo que obviamente puede conducir a problemas de rendimiento. En Django, usar la aserción assertNumQueries en las pruebas de su unidad realmente ayuda a evitar esto, al igual que con django-devserver, un reemplazo para runserver que puede generar consultas a medida que se realizan.

Answer 5

En mi humilde opinión, el problema más grande con Django ORM es la falta de claves primarias compuestas, esto me impide usar algunas bases de datos heredadas con django.contrib.admin.

Prefiero SqlAlchemy sobre Django ORM, para proyectos donde django.contrib.admin no es importante, tiendo a usar Flask en lugar de Django.

Django 1.4 está agregando algunas herramientas agradables de "proceso por lotes" para el ORM.

Answer 6

Otra respuesta de un ventilador de Django, pero:

• Si utiliza la herencia y la consulta de las clases padre, no se puede lograr que los niños (mientras puedas con SQLAlchemy).
• Group By y Having cláusulas son realmente difíciles de traducir utilizando el aggregate/annotate.
• Algunas consultas el ORM hacen son ridículamente larga, ya veces y hasta con cosas como model.id IN [1, 2, 3... ludicrous long list]
• hay una manera de pedir prima, donde "cosas es en el campo" usando __contains, pero no "campo se encuentra en la materia" . Como no existe una forma portátil de hacerlo a través de DBMS, escribir SQL sin procesar es realmente molesto. Aparecen muchos casos de borde pequeño como este si su aplicación comienza a ser compleja, porque como dijo @Gary Chambers, los datos en el DBMS no siempre coinciden con el modelo OO.
• Es una abstracción, y a veces, the abstraction leaks.

Pero más que a menudo, las personas que conozco que no quieren usar un ORM lo hacen por el motivo equivocado: la pereza intelectual. Algunas personas no harán el esfuerzo de intentar algo justo porque saben algo y quieren apegarse a él. Y da miedo cuántos de ellos puedes encontrar en informática, donde una buena parte del trabajo consiste en mantenerte al día con las cosas nuevas.

Por supuesto, en alguna área simplemente tiene sentido. Pero generalmente alguien con buenas razones para no usarlo, lo usará en otros casos. Nunca conocí a un científico de la computación serio que dijera todo, solo personas que no lo usaban en algunos casos y que podían explicar por qué.

Y para ser justos, muchos programadores no son informáticos, hay biólogos, matemáticos, profesores o Bob, el chico de al lado que solo quiere ayudar. Desde su punto de vista, es perfectamente lógico no pasar horas aprendiendo cosas nuevas cuando puedes hacer lo que quieras con tu caja de herramientas.