Abstração de banco de dados - está sendo exagerada?

Depois de ser exposto a várias camadas de abstração de banco de dados, estou começando a me perguntar qual é o sentido de toda biblioteca inventar seu próprio paradigma diferente para acessar dados. Escolher um novo DAL é como aprender um novo idioma novamente, quando geralmente tudo o que eu quero fazer é convencer a camada a gerar uma consulta SQL que eu já escrevi na minha cabeça.

E isso sem sequer tocar na legibilidade após o fato:

# Exhibit A:  A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
    .inner_join(db.ips_x_users.user_id == db.users.id)
    .select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)

# Exhibit B:  Another typical DAL
rows = db.ips_x_users
    .join(db.users, on=db.ips_x_users.user_id == db.users.id)
    .filter(db.ips_x_users.ip_addr == '127.0.0.1')
    .select(sort=~db.ips_x_users, limit=10)

# Exhibit C:  A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
             INNER JOIN users ON
                 (ips_x_users.user_id = users.id)
             WHERE ips_x_users.ip_addr = ip
             ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')

O que há de errado com a sintaxe SQL padrão? Foi criado para uma finalidade específica e se encaixa perfeitamente nessa finalidade. Talvez seja só eu, mas entendo o trecho C muito mais facilmente do que os dois primeiros. As palavras-chave renomeadas e os truques de sintaxe são fofos, mas o IMO, quando se trata de detalhes, não facilita a recuperação de linhas para o codificador.

Isso provavelmente pareceu um longo discurso, mas não é uma questão real aqui. Como todo DAL parece inventar uma nova DSL para consultas, em vez de apenas analisar o SQL testado e comprovado, deve haver benefícios em usar sintaxe diferente ou deficiências na sintaxe padrão do SQL que não sei que existem. Alguém poderia apontar o que estou negligenciando aqui?

O problema mais fundamental do uso comum de SQL é que as consultas SQL são seqüências de caracteres, que são de alguma forma compostas de outra linguagem. É aqui que as injeções de SQL e outras vulnerabilidades e WTFs são originárias (seu exemplo é muito mal escolhido, porque sua consulta não possui realmente nenhum parâmetro).

O próximo problema é na verdade um corolário: se você apenas tiver algum SQL escrito em seu código, o compilador não poderá fazer nada a respeito. Erros como erros de digitação nos nomes das colunas aparecerão apenas em tempo de execução. Isso é basicamente o motivo pelo qual você não deseja apenas uma representação de string da sua consulta no código-fonte, mas algo que o compilador possa analisar estaticamente para impedir 95% de todos os bugs de facepalm.

E o último problema ocorre quando você tenta mapear um banco de dados relacional para a semântica de idiomas e o modelo de programação: os RDBMSs não combinam bem com o OOP (ou recuperação de dados de navegação). Na verdade, é uma péssima idéia combinar esses dois, mas é para isso que servem todos os DALs orientados a objetos para bancos de dados SQL (ou seja, ORMs). Mas todas essas camadas de abstração estão condenadas a vazar. Eu acho que é basicamente por isso que existem tantos: como você trabalha com eles, vê que eles são defeituosos, você decide escrever um DAL que faça o que é certo e, finalmente, falhe.

Portanto, enquanto os problemas um e dois sugerem ter DALs que se livrem do SQL, o problema três implica que não há solução direta de ter um (pelo menos para OOP) e, portanto, sempre haverá um mar de DALs com diferentes pontos fortes e limitações. No final, tudo o que você pode fazer é escolher com cuidado alguns e cumpri-los.

Você está ignorando o fato óbvio de que nem todas as plataformas de banco de dados aceitam a mesma sintaxe SQL, portanto, a incorporação de instruções SQL em todo o aplicativo simplesmente não funcionará para todas as plataformas de banco de dados. Se você precisar suportar várias plataformas de banco de dados, precisará repensar a maioria (se não todas) dessas instruções SQL.

Sinto que o SQL está passando pela mesma grande mudança que os ponteiros sofreram há 10 anos. Há uma tentativa contínua de eliminar o trabalho manual com SQL e levá-lo a um nível de abstração mais alto. O mesmo aconteceu com os ponteiros e com o gerenciamento manual de memória há muitos anos.

Como o trabalho está atualmente em andamento, você gosta de ver muitas abordagens diferentes sugeridas, experimentadas, abandonadas e integradas. Tenho certeza de que veremos mais antes de algum tipo de abordagem comum ou padrão da indústria, se você desejar se manifestar.

Certamente oferece uma vantagem quando você pode manipular o código de acesso a dados no mesmo nível e com o mesmo paradigma aplicado ao trabalhar com o código do aplicativo.

Em poucas palavras - simplificação, agilidade, rapidez, esses são os objetivos.

Joel escreveu um belo artigo há 10 anos: Não deixe que os astronautas da arquitetura o assuste

Eu acho que é exatamente o caso. Eu estava usando a camada de abstração em meus próprios aplicativos desde que encontrei um padrão e foi fácil fazer isso dessa maneira. Mas era meu DAL que eu conhecia cada linha do código fonte => controle total. Mas eu não sugeriria usar essa estrutura para ninguém fora da minha equipe / projetos.

Quando você usa algo assim, é importante saber como é implementado, isso significa que você deve gastar muito tempo aprendendo a biblioteca / ferramenta. Se você não tiver tempo para aprender, não use. Mesmo que pareça muito fácil desde o início.