A pergunta sobre aninhadas Coleções em Eficiência Django e consulta

votos
6

Eu vejo um monte de respostas como este:

Impressão de uma lista de pessoas com mais de uma casa a cada casa com mais de um

Eu tentei essa resposta com modelos similares e parece que uma maneira terrivelmente ineficiente de fazer isso. Cada iteração parece fazer uma consulta separada por vezes, resultando em milhares de consultas para um banco de dados. Sei que você pode armazenar em cache os conjuntos de consulta, mas ainda parece muito errado. Então a questão é, você usa esse método? Se não, como você faz isso?

Publicado 13/04/2009 em 01:22
fonte usuário
Em outras línguas...                            


2 respostas

votos
6

Esta é uma pergunta muito boa, e não se limitando a estrutura ORM do Django.

Eu sempre sinto que é importante lembrar alguns dos problemas que um mapeamento objeto-relacional (ORM) framework resolve:

  • CRUD orientada a objeto : Se o resto do aplicativo é baseado em princípios de orientação a objetos fortes, o acesso a persistência de dados usando objetos torna o código só que muito mais coerente, internamente consistente, e às vezes mais curto.

  • Persistência camada de encapsulamento : Um ORM fornece uma camada transparente em sua aplicação para o acesso DB. Ele incorpora todas as funções necessárias para ler / escrever dados em um ponto, o epítome do chamado período seco (não repetir-se) princípio. Isso faz com que algumas coisas muito mais fáceis: mudanças no modelo , porque todo o DB-enfrentando selecionar e inserir o código / atualização é em um ponto, em vez de todo o aplicativo, a segurança , porque todo o acesso DB passa por um local, e testes , porque é fácil para zombar de seus modelos de dados e de acesso se eles estão claramente delineados.

  • Segurança SQL : Embora seja fácil para garantir o uso SQL puro contra ataques de injeção e tal, é ainda mais fácil se você tem um quadro ORM como um único ponto de DB-contato que faz isso por você para que você nunca tem que pensar nisso.

Observe que a velocidade não está na lista. ORM é um nível de engano entre seu código e banco de dados. Nós certamente manter os designers ORM responsável por escrever uma estrutura que produz boas instruções SQL, mas um ORM se destina a fornecer code-e arquitetura de nível de eficiência, não da execução, a eficiência. Um desenvolvedor que tenha lido um livro básico em SQL será sempre capaz de obter um melhor desempenho falando diretamente para o DB.

Existem, certamente, estratégias para contrariar esta situação, e em Django esses são select_related()como ozan mencionou, e local / view / caching diversos, mas eles não vão dar-lhe o mesmo desempenho de uma instrução SQL direta. Devido a isso, eu nunca usaria um quadro ORM que não fornecer algum mecanismo para a emissão de uma instrução SQL cru nas ocasiões em que eu preciso de velocidade. Por exemplo, eu muitas vezes recorrem a SQL cru ao gerar um grande relatório do banco de dados que une muitas mesas; a maneira ORM pode demorar alguns minutos, o caminho SQL pode demorar alguns segundos.

Dito isto, eu nunca começar por se preocupar com cada consulta individual. O meu conselho para quem vem a uma camada ORM é: não babá acesso ao banco do ORM. Escrever sua aplicação ou módulo e perfil dele, aprimorando as áreas que realmente precisam do aumento de desempenho, ou usando o cache / select_related para reduzir o DB-chattiness global da sua aplicação.

Respondeu 13/04/2009 em 13:11
fonte usuário

votos
4

Você pode usar o ) Método select_related (queryset para reduzir o número de consultas de banco de dados. Você também pode especificar a profundidade, assim, no exemplo dado, se o modelo de número de telefone teve relações estrangeiras adicionais que seria usado select_related (profundidade = 2) para evitar a selecção de novos "níveis" de entidades relacionadas.

Respondeu 13/04/2009 em 03:03
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more