Quais são os benefícios de usar a abstração de banco de dados pelo ORM? [fechadas]

Estou começando a usar o ORM recomendado pela estrutura que escolho e, embora goste da idéia 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 desapareceram pela janela, como se não existissem.

A idéia do ORM é que ele está tentando me ajudar, tornando tudo independente do banco de dados. Isso parece ótimo, mas muitas vezes há uma razão pela qual escolhi um sistema de banco de dados específico. Mas, seguindo a rota independente do banco de dados, o ORM adota o menor denominador comum, o que significa que acabo com o menor conjunto de recursos (os suportados por todos os bancos de dados).

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

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

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

OMI qualquer ORM que não tem esse recurso não vale os bits que é compilado.

o ORM assume o menor denominador comum

Devo discordar da sua declaração. Vou levar nHibernate como um exemplo. Essa estrutura suporta muitos bancos de dados, incluindo os mais populares, independentemente da versão (e dos recursos suportados), assim como a maioria dos ORMs.

Nota rápida: você menciona apenas 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. No nHibernate , você tem dialetos. Ele permite que você use o mesmo código para consultar bancos de dados diferentes. Os dialetos cuidam do gerenciamento de recursos para você. A afirmação correta é essa a given dialect will try to use all the power of a given database system.

Como exemplo, considere o SqlServer2005dialeto que, quando introduzido, estava aproveitando os novos recursos de paginação do SQL Server 2005. Usar esse dialeto em vez de SqlServer2000apenas aumentar suas performances.

É claro que existem exceções, mas não encontrei nenhuma em muitos anos trabalhando com o nHibernate, e meus aplicativos são muito centrados em dados.

A ideia é clara, mas nunca fui levado ao ponto de usar uma ferramenta ORM. Não é um problema para mim escrever o SQL (ou manipular qualquer armazenamento usado). Mas, tenho o luxo de trabalhar em um número menor de projetos com vida útil mais longa do produto; portanto, uma vez que a manipulação de SQL e DB codificada manualmente esteja em vigor, ela estará em vigor. Além disso, obviamente, você pode lidar com quaisquer consultas SQL diretas necessárias, sem precisar ajustar seu processo ao modo de pensar da ferramenta ORM.

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

Você está realmente ganhando alguma coisa ao usá-los? Ou seja, você está economizando um esforço suficiente implementando uma ferramenta ORM para valer a pena usá-la e para adicionar uma complicação extra ao seu sistema? (isso é particularmente verdade em aplicativos comerciais, nos quais essa peça extra agora é um vetor extra para possíveis problemas de suporte)

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

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

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

A menos que você escreva seu próprio mapeamento ad-hoc (que é uma boa solução em muitos casos, como outros já disseram), você pode procurar alternativas como o uso de banco de dados não relacional. Alguns dizem que um banco de dados verdadeiramente de objetos é melhor, outras palavras-chave mencionadas nesse contexto são LINQ, Ruby e Tutorial D. Suponho que, ao contrário dos bancos de dados verdadeiramente relacionais, existem realmente bancos de dados de objetos. Mas, na prática, descobri que a modelagem conceitual de dados - ou seja, para descobrir quais objetos do mundo real você deseja armazenar dados e como esses objetos se relacionam - é mais importante do que descobrir como expressar seu modelo conceitual em qualquer linguagem de programação ou banco de dados.

Qual a alternativa?

Esta é uma noção interessante. Abstraindo 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) Acho que isso pode ser resolvido por ORMs específicos do banco de dados que permitem acessar os recursos específicos, mas isso pode ser apenas mais problemas do que vale a pena e é uma etapa do processo. 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? Certamente, podemos perder o acesso a alguns recursos do banco de dados por meio do ORM, mas você sempre pode acessar aqueles que usam técnicas antigas. No final, os ganhos em produtividade superam completamente as desvantagens.

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

Tudo o que um ORM faz, você pode replicar com modos de exibição, disparadores e procedimentos armazenados. Eles ajudam a abstrair o SQL bruto e podem manter os bancos de dados normalizados consistentes. Mas isso só funciona bem para casos simples. Se houver muitos dados mach para processar, eles podem se tornar um problema de desempenho. (ORMs no PHP geralmente usam os dados no lado do script, porque as cadeias do construtor SQL não podem abstrair tudo.)

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

Uma coisa que machuca ao usar ORMs é que muitos de seus fãs tendem a afirmar que não precisamos mais conhecer a teoria SQL e RDB. Os resultados variam de engraçado a totalmente catastrófico. E isso apesar dos milhões de vezes que os ORM 'fabricam e especialistas afirmam que devemos conhecer bem a teoria SQL e RDB para usar e configurar adequadamente um ORM.

Por que as pessoas usam uma ferramenta que tem seus usos em muitos, mas nem todos os contextos, em uma bala de prata mágica e universalmente aplicável está além de mim.

No ano passado, trabalhei em um aplicativo interno que mudava com frequência e fiquei muito feliz por termos usado um ORM. O aplicativo era um aplicativo de suporte para uma equipe de gerenciamento de mudanças e, à medida que o projeto maior evoluiu, nosso pequeno aplicativo ganhou novos requisitos para situações que não existiam e que não podiam ser previstas alguns meses antes.

Graças ao ORM ( Propel , em PHP), dividimos parte da lógica do código; portanto, uma função adicionou a parte "é válido para registros" da consulta e outra a parte de segurança ("mostra esses registros apenas se o usuário possui esses recursos "), ... Se a estrutura subjacente for alterada (um campo extra que deve ser levado em consideração para" validade do registro "), teremos que alterar apenas uma função, não vinte cláusulas SQL.

Viemos de uma situação em que todas (bem, a maioria) das cláusulas SQL eram armazenadas em um arquivo XML separado, portanto, "as alterações no banco de dados seriam fáceis de lidar". Acredite, eles não eram. Uma parte foi tão horrível que tive que enviá-la ao The Daily WTF .

Se uma consulta era muito complicada para ser expressa com os Critérios Propel, ou precisávamos de alguns recursos específicos do fornecedor (principalmente pesquisa de texto completo, já que estávamos usando o MySQL), não havia problema com o Propel. Você pode adicionar critérios personalizados ou, quando realmente necessário, usamos SQL bruto ( agora ainda mais fácil de combinar com objetos Propel reais). Você pode adicionar facilmente seus complementos específicos de fornecedor às classes geradas, para ter o melhor dos dois mundos: sem SQL no código do aplicativo, mas com todos os recursos do mecanismo de banco de dados.

Mas o ponto é que você começa a se afastar 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, portanto 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.

Frequentemente, os métodos fornecidos pelos próprios bancos de dados específicos são usados ​​no DB Connector, para que você obtenha essas otimizações sem precisar saber o que são.

Você ainda pode escrever funções no lado do banco de dados. Muitas vezes você pode apenas mapeá-los.

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

Os ORMs também podem fornecer acesso a recursos específicos do banco de dados, depende de qual ORM você está usando e de quais recursos ele fornece.

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

Para mim, o principal benefício do uso de um ORM não é necessariamente que ele torna um banco de dados de aplicativos independente (embora isso também seja uma coisa boa), mas que, na maioria das vezes, não preciso pensar em como as coisas são armazenadas e armazenadas. recuperado.

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

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

Evey db coisa específica está disponível. Eu só preciso escrever a consulta com a qual a biblioteca me ajuda (eu posso usar '?' E parâmetros em vez de nomear manualmente um parâmetro e usar .Add)

Acho que a minha metade é meio útil. Eu recebo ajuda no mundo do ORM e faço partes significativas no mundo das consultas.

Escrever código para inserir e selecionar, atualizar em linha ou com procs armazenados e mapeá-los de volta através do DAL é a norma mais longa e apenas benéfica no caso excepcional. Os ORMs disponíveis, os bancos de dados de suporte e os idiomas, a pergunta que você deve fazer por que não está usando o ORM?

Eles são padronizados, universais, especificados ou genéricos. além disso, é mais rápido e fácil de implementar. Eu usei subsônico, linq-to-sql e a estrutura da entidade. Ele permite que o desenvolvedor se concentre na lógica e nas regras de negócios, em vez do mapeamento do banco de dados.

Meus (simples) dois centavos:

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

2: A vantagem dos ORMs diminui na correlação direta com a complexidade da consulta que você precisa executar. Quando você tem um bom relacionamento simples - por exemplo, Usuários -> Postagens, eles podem funcionar muito bem. É por isso que a maioria dos ORMs / estruturas usa exemplos como este. Quando você precisa executar consultas complexas, no entanto, a quantidade de ORMQL que você precisa gerar é comparável ao tamanho da string de uma consulta SQL regular - mas com menos desempenho devido ao gráfico de objeto em execução que a consulta chama, o que meio que derrota o ponto de abstração. Então, em poucas palavras - os ORM são brilhantes para os primeiros 30-50% das tarefas do banco de dados -, mas terríveis para o final. Eu acho que essa é outra razão pela qual a AR é tão prevalente.

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

Pessoalmente, misturo essas abordagens:

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

Dito tudo isso, Doutrina 2 será lançada em breve, o que parece realmente interessante.

Você pode usar estruturas do mapeador SQL como myBatis se desejar utilizar os recursos sql.