ti-enxame.com

Quais são os benefícios de usar a abstração de banco de dados por ORM?

Estou começando a usar o ORM recomendado pela estrutura que escolhi e, embora goste da ideia da camada adicional de abstração que o ORM fornece, estou começando a perceber o que isso realmente significa. Isso significa que não estou mais trabalhando com meu banco de dados (mysql) e quaisquer recursos específicos do mysql foram embora, para fora da janela, como se não existissem.

A ideia do ORM é que ele está tentando me ajudar tornando tudo agnóstico em banco de dados. Isso parece ótimo, mas geralmente há um motivo pelo qual escolho um sistema de banco de dados específico. Mas, seguindo a rota agnóstica de banco de dados, o ORM usa o menor denominador comum, o que significa que acabo com o menor conjunto de recursos (aqueles suportados por todos os bancos de dados).

E se eu souber que, a longo prazo, não trocarei o banco de dados subjacente? Por que não acessar os recursos específicos do banco de dados também?

19
jblue

Eu vejo isso da mesma maneira. Qualquer abstração que não permite que você fique por baixo dela quando necessário é má, porque leva a todos os tipos de inversões de abstração feias em seu código.

No trabalho, temos um ORM interno que funciona muito bem, mas para os momentos em que precisamos de algo que seus recursos não fornecem explicitamente, há um método que pega uma string e a solta diretamente na consulta que está gerando, permitindo para o uso de SQL bruto quando for necessário.

IMO, qualquer ORM que não tenha esse recurso não vale os bits dos quais foi compilado.

14
Mason Wheeler

o ORM leva o menor denominador comum

Devo discordar de sua declaração. Vou usar nHibernate como exemplo. Este framework suporta muitos bancos de dados, incluindo os mais populares, independente da versão (e recursos suportados), assim como a maioria dos ORMs.

Nota rápida: você apenas menciona a abstração do banco de dados. Esse é um dos muitos benefícios, mas eu realmente acho que os recursos orientados a objetos são mais poderosos (por exemplo: herança). E You design your domain model first...

... De volta à abstração. Não é o menor denominador comum. Em nHibernate, você tem dialetos. Ele permite que você use um mesmo código para consultar bancos de dados diferentes. Os dialetos cuidam do gerenciamento de recursos para você. A afirmação correta é que a given dialect will try to use all the power of a given database system.

Como exemplo, pegue o SqlServer2005 dialeto que, quando introduzido, estava aproveitando os novos recursos de paginação do SQL Server 2005. Usando esse dialeto em vez de SqlServer2000 apenas impulsionou suas performances.

Claro que há exceções, mas eu não encontrei nenhuma em muitos anos de trabalho com o nHibernate, e meus aplicativos são muito centrados em dados.

14
user2567

A ideia é ótima, mas nunca fui levado ao ponto de usar uma ferramenta ORM. Simplesmente não tem sido um problema para mim escrever o SQL sozinho (ou lidar com qualquer armazenamento usado). Mas, eu tenho o luxo de trabalhar em um número menor de projetos com vida útil mais longa do produto, então, uma vez que a manipulação de SQL e DB codificada manualmente esteja pronta, ela está pronta. Além disso, você obviamente pode lidar com quaisquer consultas SQL diretas de que precisar, sem ter que ajustar seu processo à maneira de pensar da ferramenta ORM.

Então, acho que as perguntas devem ser antes de você pular para uma:

Você está na verdade ganhando alguma coisa ao usá-los? Ou seja, você está economizando uma quantidade suficiente de esforço ao implementar uma ferramenta ORM para fazer valer a pena usar e adicionar uma complicação extra ao seu sistema? (isto é particularmente verdadeiro para aplicativos comerciais, onde aquele 'pedaço' extra agora é um vetor extra para problemas de suporte em potencial)

E então, a camada extra de abstração terá um impacto negativo no aplicativo? Será mais lento do que SQL codificado manualmente, etc.

5
GrandmasterB

O/R-M tem sido criticado regularmente. Ted Neward chamou isso de " Vietnã da Ciência da Computação " alguns anos atrás. O/R-M

começa bem, fica mais complicado com o passar do tempo e em pouco tempo aprisiona seus usuários em um compromisso que não tem um ponto de demarcação claro, nenhuma condição de vitória clara e nenhuma estratégia de saída clara.

A menos que você apenas escreva seu próprio mapeamento ad-hoc (o que é uma boa solução em muitos casos, como outros já disseram), você pode olhar para alternativas, como usar banco de dados não relacional. Alguns dizem que um banco de dados de objeto verdadeiro é melhor; outras palavras da moda mencionadas neste contexto são LINQ, Ruby e Tutorial D. Suponho que, em contraste com bancos de dados verdadeiramente relacionais, existem bancos de dados de objeto verdadeiramente. Mas, na prática, descobri que a modelagem conceitual de dados - ou seja, descobrir sobre quais objetos do mundo real você deseja armazenar dados e como esses objetos se relacionam entre si - é mais importante do que descobrir como expressar seu modelo conceitual em qualquer linguagem de programação ou banco de dados.

5
Jakob

Um ORM basicamente equivale a "Procedimentos não armazenados". Lá, eu criei um termo.

Tudo que um ORM faz, você pode replicar com Views, Triggers e Stored Procedures. Eles ajudam a abstrair SQL bruto e podem manter os bancos de dados normalizados consistentes. Mas só funciona bem para casos simples. Se houver muitos dados mach para processar, eles podem prejudicar o desempenho. (ORMs em PHP geralmente usa o lado do script de dados, porque as cadeias de construção SQL não podem abstrair tudo).

Mas, como sempre, tudo depende do aplicativo e da tarefa em questão.

3
mario

Qual é a alternativa?

Esta é uma noção interessante. Ao abstrair os recursos do banco de dados subjacente, definitivamente perdemos alguns dos recursos da implementação específica do banco de dados. (Se devemos ou não depender de recursos específicos do banco de dados é outro argumento) Eu acho que isso poderia ser resolvido por ORMs específicos do banco de dados que permitem que você acesse os recursos específicos, mas isso pode ser mais problemático do que vale e uma etapa no direção errada.

No final do dia, você deve se perguntar - qual é a alternativa?

Devemos parar de usar ORMs e voltar a escrever todos os acessos ao banco de dados nós mesmos? Claro que podemos perder o acesso a alguns recursos do banco de dados por meio do ORM, mas você sempre pode acessá-los usando técnicas tradicionais. No final, os ganhos que você obtém em produtividade superam completamente as desvantagens.

3
Jaco Pretorius

Uma coisa que dói usar ORMs é que muitos de seus fãs tendem a alegar que não precisamos mais conhecer a teoria SQL e RDB. Os resultados variam de engraçados a totalmente catastróficos. E isso apesar das milhões de vezes que os fabricantes e analistas de ORM 'afirmam que nós devemos saber a teoria de SQL e RDB para usar e configurar adequadamente um ORM.

Por que as pessoas transformam uma ferramenta que tem seus usos em muitos, mas não em todos os contextos, em uma bala de prata universalmente aplicável está além da minha compreensão.

3
luis.espinal

Eu escrevi o meu próprio, o que me ajuda a fazer seleções e inserções mais fáceis.

Cada coisa específica do banco de dados está disponível. Eu só preciso escrever a consulta com a qual a biblioteca me ajudará (posso usar '?' E params em vez de nomear manualmente um parâmetro e usar .Add)

Acho que a minha metade é uma merda metade útil. Recebo ajuda no mundo ORM e faço partes significativas no mundo da consulta.

1
user2528

Mas a questão é que você programa longe do banco de dados, o que significa que você não precisa pensar como se estivesse no banco de dados.

Eu trabalho em C # agora e uso muito o LINQ, então muitos e muitos métodos fluentes. Não preciso pensar em como meus objetos são armazenados ou encontrados, ou mesmo salvos no nível do programa, e muito pouco no nível da camada de negócios.

Muitas vezes, os métodos fornecidos pelos próprios bancos de dados específicos são usados ​​no Conector de banco de dados, portanto, você obtém essas otimizações sem precisar saber o que são.

Você ainda pode escrever funções do lado do banco de dados. Freqüentemente, você pode simplesmente mapeá-los.

E, acima de tudo, uma separação como essa permite testabilidade e força você (um pouco) a escrever um código melhor estruturado

1
Dan

ORMs pode fornecem acesso a recursos específicos do banco de dados também, depende de qual ORM você está usando e quais recursos ele oferece.

Por exemplo, no projeto atual em que estou trabalhando, estamos usando a Java API de persistência e Hibernate. Mesmo assim, usamos vários recursos específicos do banco de dados, como pesquisa em tabelas com soundex.

Para mim, o principal benefício de usar um ORM não é necessariamente que ele torne um banco de dados de aplicativo agnóstico (embora isso também seja uma coisa boa), mas que eu, na maioria das vezes, não tenho que pensar sobre como as coisas são armazenadas e recuperado.

No entanto, em algum momento você provavelmente terá que pensar sobre isso de qualquer maneira, dependendo dos requisitos de seu aplicativo. O ORM não é mágico.

1
Vetle

Meus (simples) dois centavos:

1: Existem ORMS e existem ORMS. Alguns ORMS são baseados em Active Record, outros baseados em Data Mapper - isso em si é uma consideração relevante, mas que requer alguma investigação para entender as implicações. Em geral - minha experiência em PHP é que ORMS suporta o primeiro, poucos suportam o último. ORMs baseados em Active Record parecem ter um de dois efeitos - eles desnormalizam o banco de dados ou invocam uma infinidade de classes para oferecer suporte a interações de objetos.

2: A vantagem dos ORMs diminui em correlação direta com a complexidade da consulta que você precisa executar. Quando você tem um relacionamento simples e agradável - ou seja, Usuários -> Postagens, eles podem funcionar muito bem. É por isso (IMO) que a maioria dos ORMs/frameworks usa exemplos como este. Quando você precisa executar consultas complexas, no entanto, a quantidade de ORMQL que você precisa gerar é comparável ao comprimento da string de uma consulta SQL regular - mas tem menos desempenho devido ao gráfico de objeto que executa a consulta, o que meio que frustra o ponto de abstração. Então, em poucas palavras - ORMs são brilhantes para os primeiros 30-50% de suas tarefas de banco de dados - mas terríveis para o último. Acho que essa é outra razão pela qual a RA é tão prevalente.

3: Por que se esconder do banco de dados? Você usaria uma linguagem do lado do servidor para abstrair o javascript?

Pessoalmente, eu misturo essas abordagens:

  • use ORM para o básico, carregando "usuários"
  • use um DAO contendo várias consultas SQL pré-preparadas (ou seja, selectLike, selectWhere).
  • estenda o DAO onde necessário para adicionar consultas personalizadas mais específicas, mas reutilizáveis
  • Fornece acesso simples ao banco de dados por meio do DAO - ou seja, $ data = Dao-> query (sua string sql) para executar consultas únicas.

Tendo dito tudo isso, Doctrine 2 será lançado em breve, o que parece muito interessante.

1
sunwukung

Você pode usar estruturas de mapeamento SQL como myBatis se quiser utilizar recursos sql.

0
kolchanov