Alguém que trabalhou extensivamente em SQL com pelo menos dois principais produtos de banco de dados (como Oracle, SQL Server, Informix, Sybase, DB2, Teradata) sabe como os dialetos SQL do fornecedor de banco de dados são diferentes entre si? Como tenho experiência em Oracle, estou especialmente interessado em
- funções analíticas
- cláusulas modelo
- consultas hierárquicas (
start with .. connect by
vem à mente) - qualquer outra característica que seja mais do que o habitual (
select x, y from a, b where...
)
Provavelmente, a questão se resume a se e até que ponto esses recursos são regulados por um padrão ansi.
Na prática, gostaria de saber se existe uma "regra prática" que indicaria se (e como) posso pegar uma instrução SQL DML que é executada em um banco de dados e deixá-la ser executada em outro banco de dados.
ANSI é uma organização privada sem fins lucrativos que cria padrões voluntários. Como tal, na verdade, não regula nada. Freqüentemente, é benéfico para a empresa seguir padrões reconhecidos, e é por isso que muitas empresas de banco de dados seguem o padrão ANSI para SQL. É claro que, à medida que cada empresa busca diferenciar seus produtos, ela desenvolverá funcionalidades adicionais além dos padrões.
De w3schools :
As diferenças entre os dialetos SQL são muito grandes nas áreas mais especializadas que você listou para simplificar o problema a uma “regra de ouro”. Nessas situações, você provavelmente deve converter a instrução inteira para cada banco de dados. Ao fazer isso, cada instrução pode ser otimizada para cada plataforma, aproveitando os recursos especiais que cada banco de dados pode fornecer. Escrever SQL para o menor denominador comum (ANSI) pode simplificar a migração, mas ao custo do desempenho.
SQL Dialects Reference fornece algumas comparações úteis das variantes SQL. Para obter mais informações, recomendo pesquisar os dialetos específicos entre os quais você está alternando, assim:
differences between mysql and oracle sql
Em um momento ou outro, trabalhei com todos os bancos de dados que você mencionou. Infelizmente, descobri que não leva muito tempo para a sintaxe se desviar para seus próprios sabores, para qualquer coisa que não seja o mais simples SELECT, INSERT, UPDATE e DELETE. Quando chegar a algumas das categorias que você sugere, ele será rapidamente específico do fornecedor. Eu sempre tive que 'portar' meu SQL de uma plataforma para outra. Embora voltando alguns anos, fiquei surpreso com a diferença entre o SQL Server e o Teradata SQL, mesmo para uma ATUALIZAÇÃO com algumas junções.
Cada fornecedor geralmente está em conformidade com um núcleo mínimo de sintaxe padrão. O SQL-92 é geralmente o padrão mais compatível. Eles então adicionam funcionalidade adicional em cima disso. O SQL3 adiciona funcionalidade de procedimento ao padrão de sintaxe. A conformidade com esse padrão é muito menor. Os fornecedores geralmente farão reivindicações de certa conformidade. A conformidade com o padrão significa apenas que eles fornecem "pelo menos" essa funcionalidade. Eles podem fornecer qualquer quantidade de funcionalidade e, portanto, sintaxe além desse padrão. Cada fornecedor de banco de dados também adiciona funcionalidade específica à maneira como implementa sua estrutura de banco de dados. É assim que cada fornecedor de banco de dados tenta fornecer uma vantagem sobre a concorrência.
Apenas jogando para discussão, mesmo que provavelmente tenha sido um comentário também. É por isso que a maioria das pessoas gosta de usar as várias estruturas hoje em dia, como EntityFramework e LINQ, onde toda a abstração subjacente da consulta é relegada à camada do aplicativo, e a camada de dados é apenas armazenamento plano.
Observe que isso oferece outro benefício para a turma do NoSQL, pois o banco de dados é apenas um meio de armazenamento.
Alguns fornecedores de banco de dados fornecem informações detalhadas sobre sua conformidade com o padrão ANSI SQL. Para Teradata, eles listam especificamente os padrões SQL para cada elemento do padrão ANSI e para cada item detalhado - como para cada função, tipo de dados etc. Não vi afirmações gerais sobre a conformidade do Teradata, mas pesquisei dois documentos para "SQL:2", que obteria qualquer conformidade ANSI recente. Eles são compatíveis com ANSI SQL:2011 para tudo, exceto gatilhos, procedimentos armazenados e literais hexadecimais, que são compatíveis com SQL:2008.
O diabo está nos detalhes, e você deve tê-los para determinar se um banco de dados é compatível com ANSI SQL em qualquer nível. Também não é suficiente para se adequar ao antigo padrão SQL-92 (também conhecido como SQL2). Se um fornecedor fornece um bom suporte para um padrão mais recente, isso não diz muito sobre a qualidade do banco de dados?
Um bom lugar para obter informações para comparar banco de dados é "SQL In a Nutshell", 2ª ou 3ª edição, de Kline, Kline e Hunt, e publicado por O'Reilly. Eles têm várias tabelas que comparam diferentes recursos de banco de dados para SQL:2003. Teradata não está na lista, mas como eles são pelo menos compatíveis com SQL:2003, posso usar a lista para comparar os recursos do banco de dados.
Olhando para as listas no livro da O'Reilly, posso encontrar recursos no Oracle que não suportam o padrão SQL:2003. Claro, preciso verificar a documentação do Oracle para verificar esses fatos, já que esse livro está datado. Então a comparação de Oracle para SQL:2003 me ajudará em meu grande projeto de conversão de Oracle para Teradata.