Quanto compatibilidade que os motores DB ter ao nível do SQL?

Question

Digamos que eu queria ter uma aplicação que pode facilmente mudar o DB no back-end.
Estou principalmente pensando em SQL Server como o back-end primário, mas com a flexibilidade para ir outro motor DB. Firebird e PostgreSQL parecem ter (do meu breve wikipedia excursão) o mais em comum w / SQL Server (mais eles são livres).

Como semelhante seria a configuração DB, acesso, consultas, etc .. ser para Firebird, PostgreSQL e MS SQL Server?

Answer 1

Eu trabalhei em um projeto onde era uma exigência absoluta para apoiar muitos bancos de dados, incluindo, pelo menos, Access, SQL Server e Oracle.

Então, eu sei que isso pode ser feito. Principalmente DML (SELECT, UPDATE, INSERT ...) é o mesmo e, certamente, nós não tivemos grandes problemas fazê-lo funcionar em todos os bancos de dados - apenas aborrecimentos ocasionais. MySQL foi a exceção, nesse momento, uma vez que simplesmente não foi suficiente capaz.

Nós encontramos a maioria das diferenças na DDL, mas com a arquitetura direita (que tínhamos), não foi difícil para corrigir isso.

A única coisa que nos causou um problema estava gerando de identificação única - autoincrement é não-padrão. Fortuantely em um banco de dados de cerca de 40 mesas, havia apenas alguns lugares onde única ID do estavam necessidade (bom design DB). No final, gerar o ID único no código, e lidar com quaisquer confrontos (tudo em transações).

Ele fez as coisas mais fáceis, porque tinha evitado usando autoincrement para campos de identificação, que é mais difícil pensar em chaves únicas -. Mas melhor no longo prazo

Answer 2

Infelizmente, SQL varia amplamente entre os fornecedores. É quase impossível escrever todos, mas o SQL mais trivial para executar em um número de RDBMS - e então você está em menor território denominador comum. Muito melhor usar uma camada de abstração para lidar com pelo menos a conexão com o banco de dados (inc. Acesso, o envio de consultas), e quer um ORM para lidar com o próprio ou SQL per-provedor SQL.

Se você quiser olhar para como eles variam -. Bons exemplos são auto-incrementando ids e obter o ID do último registro inserido

Answer 3

Bem, CRUD material deve ser o mesmo em todos os lugares, mas se você construir nada complexo, você provavelmente vai querer usar gatilhos e procedimentos armazenados e é aí que a compatibilidade torna-se baixo. Escrevendo um aplicativo DBMS agnóstico geralmente significa passar a maior parte do lado de fora de lógica de negócios de banco de dados, assim que ter um aplicativo de camada 3 é, IMHO, uma obrigação em tal caso.

Como alternativa, você poderia usar alguma biblioteca wrapper que funciona como camada de abstração, mas ainda estou para ver um que é capaz de fazer o trabalho corretamente em uma faixa de DBMS-es. Claro, que também é dependente da linguagem de programação que você usa.

Answer 4

Como apontado por outras respostas, DBMS variar muito, uma vez que vão além coisas básicas SELECT / inserção (e às vezes até lá).

Nós também temos que manter compatibiliy em vários DBMS. Na minha opinião a melhor abordagem é geralmente de usar algum tipo de camada de compatibilidade. Temos um DB biblioteca de abstração em casa, mas existem várias ferramentas disponíveis.

Em particular, pode pagar para olhar para ORMs populares (Hibernate, nHibernate etc.). Eles normalmente oferecem DB-independência como uma espécie de efeito colateral. Pelo menos Hibernate também tem uma linguagem de consulta especial que será automaticamente traduzido para SQL para o SGBD que você está usando.