una pregunta acerca anidadas Colecciones en Django y consultas Eficiencia

Question

veo un montón de respuestas como ésta:

Printing a list of persons with more than one home each home with more than one

me han tratado esa respuesta con modelos similares y parece que una manera terriblemente ineficiente de hacer esta. Cada iteración parece hacer una consulta separada que a veces resulta en miles de consultas a una base de datos. Me doy cuenta de que puede almacenar en caché los conjuntos de consultas, pero todavía parece muy incorrecto. Entonces la pregunta es, ¿usas ese método? Si no, ¿cómo lo haces?

Answer 1

Esta es una muy buena pregunta, y no está limitada al marco ORM de Django.

siempre siento que es importante recordar algunos de los problemas que un mapeo objeto-relacional (ORM) Marco resuelve:

• CRUD orientada a objetos: Si el resto de la aplicación se basa en principios sólidos orientados a objetos, el acceso a la persistencia de datos utilizando objetos hace que el código sea mucho más coherente, internamente consistente y, a veces, más corto.

• Encapsulación de capas de persistencia: Un ORM proporciona una capa clara en su aplicación para el acceso a bases de datos. Encapsula todas las funciones necesarias para leer/escribir datos en un solo lugar, el epítome del llamado principio DRY (no te repitas). Esto hace algunas cosas mucho más fáciles: el modelo cambia, porque todo el código de selección e inserción/actualización de DB está en un punto en lugar de en toda la aplicación, seguridad, porque todos los accesos de DB pasan por una ubicación y probando, porque es fácil burlarse de sus modelos de datos y acceder si están claramente delineados.

• seguridad de SQL: Si bien es fácil asegurar el uso de SQL prima frente a los ataques de inyección y tal, es aún más fácil si usted tiene un marco ORM como un único punto de DB-contacto que lo hace por usted para que nunca tenga pensar en eso

Observe que la velocidad no está en la lista. Un ORM es un nivel de indirección entre su código y la base de datos. Ciertamente, responsabilizamos a los diseñadores ORM por escribir un marco que produzca buenas sentencias SQL, pero un ORM está destinado a proporcionar eficiencia a nivel de código y arquitectura, no eficiencia de ejecución. Un desarrollador que haya leído un libro básico sobre SQL siempre podrá obtener un mejor rendimiento hablando directamente con el DB.

Sin duda existen estrategias para contrarrestar esto, y en Django esos son select_related() como lo mencionó ozan, y site/view/miscellaneous caching, pero no le darán el mismo rendimiento que una instrucción SQL directa. Debido a esto, nunca usaría un marco ORM que no proporcione algún mecanismo para emitir una instrucción SQL sin procesar en aquellas ocasiones en que necesito velocidad. Por ejemplo, a menudo recurro a SQL sin procesar al generar un informe grande fuera de la base de datos que une muchas tablas; la forma ORM puede tardar minutos, la forma SQL puede tomar segundos.

Dicho esto, nunca empiezo por preocuparme por cada consulta individual. Mi consejo para cualquier persona que ingrese a una capa ORM es: no atienda el acceso a la base de datos de ORM. Escriba su aplicación o módulo, y luego perfile, modificando las áreas que realmente necesitan el aumento de rendimiento, o usando el almacenamiento en caché/select_related para reducir el chat-DB general de su aplicación.

Answer 2

Puede usar el select_related() queryset method para reducir el número de consultas a la base de datos. También puede especificar la profundidad, por lo que en el ejemplo dado si el modelo de número de teléfono tenía relaciones extranjeras adicionales, usaría select_related (depth = 2) para evitar seleccionar más "niveles" de entidades relacionadas.