Quando usar um ORM (Sequela, Datamapper, AR, etc.) vs.puro SQL para consultar

StackOverflow https://stackoverflow.com/questions/2073502

Pergunta

Um colega meu está actualmente a concepção de consultas SQL, como esta abaixo, para produzir relatórios, que são apresentados em arquivos do excel através de uma consulta a dados externos.Actualmente, apenas a processos de informação na base de dados são necessários (sem operações de CRUD).

Eu estou tentando convencê-lo de que seria melhor usar um rubi ORM, a fim de ser capaz de exibir os dados em um carris/sinatra app.

Apesar das vantagens óbvias na exibição de dados, que vantagens existem para ele, para aprender a usar um ORM como Sequela ou Datamapper?

As consultas SQL que ele está escrevendo são claramente bastante complexa, e de ser relativamente novo no SQL, muitas vezes ele reclama que é muito demorado e confuso.É possível escrever consultas extremamente complexas com um ORM?e se assim for, qual é o mais adequado(eu ouvi Sequela é bom para o legado de dbs)?e quais são as vantagens de aprender ruby e utilizar um ORM versus furando com SQL puro, na tomada de complexo de consultas de banco de dados?

Foi útil?

Solução

Eu sou o mantenedor do Datamapper e, para relatórios complexos, você deve usar o SQL.

Embora eu pense que algum dia teremos uma DSL que fornece o poder e a concisão do SQL, tudo o que vi até agora exige que você escreva mais código Ruby do que SQL para consultas complexas. Prefiro manter uma consulta SQL de 5 linhas do que 10 a 15 linhas de código Ruby para descrever a mesma operação complexa.

Observe que eu digo complexo .. Se você tem algo simples, use os localizadores de construção do ORM. No entanto, acredito que existe uma linha que você pode atravessar onde o SQL se torna mais simples. Agora, a maioria dos aplicativos não está apenas relatando. Você pode ter muitas operações do tipo CRUD, para as quais um ORM é perfeitamente adequado e muito melhor do que fazer essas coisas manualmente.

Uma coisa que um ORM geralmente fornece é algum tipo de organização para a lógica do seu aplicativo. Você pode agrupar o código com base em cada modelo no mesmo arquivo. Geralmente é lá que eu colocarei a complexa consulta SQL, em vez de incorporá -la no controlador, por exemplo:

class User
  include DataMapper::Resource

  property :id,   Serial
  property :name, String,  :length => 1..100, :required => true
  property :age,  Integer, :min => 1, :max => 130

  def self.some_complex_query
    repository.adapter.select <<-SQL
      SELECT ...
        FROM ...
       WHERE ...
       ... more complex stuff here ...
    SQL
  end
end

Então eu posso apenas gerar o relatório usando User.some_complex_query. Você também pode empurrar a consulta SQL para uma visão se quiser limpar ainda mais esse código.

EDIT: Por "Visualizar" na frase acima, eu quis dizer RDBMS View, em vez de visualizar no contexto do MVC. Só queria esclarecer qualquer confusão em potencial.

Outras dicas

Se você estiver escrevendo suas consultas manualmente, terá a chance de otimizá -las. Quando olho para essa consulta, vejo algum potencial para otimizações (e.icGroupName como '%San-Fransisco%' ou e.icGroupName como '%bordeaux%' não usará um índice = digitalização da tabela).

Ao usar um mapeador (objetos/tabelas nativos) para relatar, você não tem ou pouco controle sobre a consulta SQL resultante.

Mas: você pode colocar essa consulta em uma visão ou procedimento armazenado e mapear essa exibição/proc com um mapeador ou. Você pode otimizar suas consultas e Você pode usar todos os recursos da sua estrutura de aplicativos.

A menos que você esteja lidando com objetos, um ORM não é necessário. Parece que seu amigo simplesmente precisa gerar relatórios; nesse caso, o SQL puro é bom, desde que ele saiba o que está fazendo (por exemplo, evitando problemas de injeção de SQL).

ORM significa "Mapeamento Relacional de Objetos". Se você não tem o "O" (objetos), provavelmente não é um bom ajuste para o seu aplicativo. Onde o ORMS realmente brilha está em objetos persistentes no banco de dados e carregando -os de um banco de dados.

ORM significa mapeamento relacional de objetos - mas, olhando para a consulta que seu amigo parece estar querendo uma tabela bastante específica de somas e outros itens ... Eu não usei a sequência de Ruby, mas usei o Hibernate e o Sqlalchemy de Python (para Django/Turbogears) e, embora você possa fazer esse tipo de dúvida, não acredito que essa seja a força deles.

O poder do ORM vem de poder encontrar relacionamentos com objetos de barra, digamos que você deseja todos os objetos da barra para o campo de Foo maior que x ... esse tipo de coisa. Portanto, eu não classificaria um ORM como uma solução "boa", apesar de me mudar para uma linguagem de programação real como Ruby e fazer o SQL através dela em vez de Excel ... que por si só é uma vitória.

Apenas meus 2 centavos.

Em uma situação como essa, eu provavelmente os escrevia manualmente ou usaria uma visualização (se o banco de dados que você está usando suporta vistas)

ORM são usados quando você tiver Objetos (Objetos de Negócios).Por isso, estou assumindo que você tenha uma aplicação com a qual você criar e Gerenciar os Objetos de Negócios que são, em última análise, salvo no banco de dados.Se você tem, então você tem quase definitivamente tem alguma representação das relações e, provavelmente, muitos dos cálculos que você vai usar em relatórios.O problema com o uso de SQL para acessar diretamente o banco de dados para os relatórios é simplesmente a capacidade de manutenção.Normalmente você colocar um monte de esforço para assegurar que o seu Negócio Objetos ocultar quaisquer detalhes da sua base de dados.Implementar regras de negócio e de fazer cálculos comuns em seus Objetos de Negócio.Construir uma linguagem comum para todos os membros da equipe, etc, etc.Em seguida, você usar um ORM para mapear para o banco de dados e usar Habanero ou NHibernate ou algo parecido para fazer isso.Isso tudo é ótimo.Fazemos isso tudo em nome da Manutenção e é ótimo.Você pode migrar seu aplicativo altere seu design, etc, etc.

Você agora vá e escrever SQL para gerar relatórios sobre o tempo que você tem centenas de relatório.Em primeiro lugar, eles muitas vezes duplicar a lógica que você já tem em seu BusinessObjects (Geralmente, sem quaisquer testes) e, pior ainda Bham Damb desculpe a manutenção do agora é recheado esqueça de mover um campo de uma tabela para outra se esqueça de cerca de dividir a tabela em duas alterar essa relação, etc, você tem uma série de relatórios que vão quebrar inesperadamente.

O problema com quering através do seu Domínio de Objetos/a Business Objects é simplesmente um de desempenho.

Em resumo, se você estiver usando o Domain Driven Design, ou o Objecto de Negócio conceitos tentar usar esses relatórios.(Você provavelmente será executado diretamente do banco de dados usando SQL ou procedimentos armazenados por motivos de desempenho, mas tente limitar essas utilizar o seu Negócio de Objectos em primeiro lugar e, em seguida, usar o SQL).A outra opção, claro, é uma banco de dados de relatórios (Como alguns dos conceitos de BI) O mapeamento do seu transacional do banco de dados para a elaboração de seus relatórios DB é, portanto, em um só lugar e facilmente mutável em casos onde você deseja mudar o seu projeto.

Objetos de domínio (Business Objects) e Realiza ter todo o conhecimento, para permitir que você para iniciar a construção de alto desempenho de consultas que são executados diretamente no Banco de dados enquanto estiver usando o Domínio de Terminologia.Vamos esperar que estes continuam a evoluir a um ponto onde isso é uma realidade.

Até então, se você estiver usando Objetos de Negócio em seu aplicativo tentar usá-los para relatar quando o desempenho é um problema resort para SQL.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top