Existe alguma coisa como SQL portátil?

Question

Existe alguma coisa como SQL portátil?

na minha experiência, embora exista um padrão SQL, é bastante difícil escrever SQL que funciona, não modificado, sobre um grande número de RDBMS.

assim, eu gostaria de saber se existe um subconjunto de SQL (incluindo DDL, schemas, etc) que é conhecido por trabalhar em todos os RDBMS principais, incluindo PostgreSQL, MySQL, servidor SQL e, por último, mas não menos importante, Oracle. Que tipo de armadilhas devem ser evitadas ao escrever SQL portátil?

A propósito, existe um projecto que o objetivo é traduzir um subconjunto Válido de SQL para os dialetos específicos usados por todos esses fornecedores? Eu sei que hibernar e outros sistemas ORM têm que fazer isso, mas eu não quero ORM, eu quero escrever diretamente para a base de dados SQL.

Obrigado!

20

sql portability

Author: Luís Pureza, 2011-04-13

Source

5 answers

Dentro de cada RDBMS, o que quer que esteja listado como compatível com ANSI deve ser o mesmo em todos eles que é o verdadeiro padrão. No entanto, ao ficar com apenas ANSI (ou seja, portátil) coisas, então você perde para fora na funcionalidade otimizada, específica do Fornecedor. Além disso, só porque PostgreSQL implementa uma função ANSI não significa que ela está disponível em qualquer outro RDBMS (mas se ela está disponível, então ela deve funcionar da mesma forma).

Pessoalmente, não vejo valor em código SQL verdadeiramente portátil ou um projeto para normalizar até um menor denominador comum definido como cada RDBMS particular é otimizado de forma diferente. Não existe uma língua de Aplicação comum. Se você está usando C#, então você não estaria querendo usar coisas que só podem ser encontradas em PHP ou JAVA. Por isso, abraça a plataforma em que estás :).

Editar: Se estiver a escrever uma aplicação que possa ligar-se a vários RDBMS diferentes, terá provavelmente de encontrar o SQL apropriado para cada plataforma em particular, tal como o os autores de cada uma das ORM tiveram que fazer.

2

Author: Solomon Rutzky, 2011-04-13 15:00:18

As perguntas simples são quase sempre portáteis. Infelizmente, a lista de fornecedores SQL que você forneceu variam muito em sua conformidade de padrões. MS SQL Server está no topo dos que você listou em termos de conformidade com os padrões ANSI SQL, e tanto MySQL e Oracle são notoriamente ruim quando se trata de Conformidade de padrões. Isso, é claro, não quer dizer que eles são motores ruins RDBMS ou que você não pode escrever poderosas consultas com eles, mas sua adesão aos padrões não é exactamente o que eles são conhecidos. Note que omitiu alguns grandes jogadores do RDBMS nessa lista, nomeadamente o Sybase e o DB2 da IBM. Esses dois são geralmente mais compatíveis com os padrões do que os outros, se isso valer de alguma coisa.

1

Author: Adam Robinson, 2011-04-13 13:54:10

O ideal de escrever o código SQL num produto e esperar que funcione noutro sem modificação é um sonho impossível.

Eu, ao invés de pensar "portabilidade" como sendo um meaure de como é fácil mover o código para outra SQL produto ou, o que é fundamental, para uma versão posterior do SQL mesmo produto, observando o estabelecido SQL produtos tendem a mover - para padrão SQL (por exemplo, SQL-92 do UPDATE requer subconsultas escalares, portanto, é prolixo, SQL Server cedo proved proprietary JOIN..FROM syntax then for SQL Server 2008 provided a MERGE syntax which supports and extends Standard SQL's MERGE).

Como regra geral, use o código SQL padrão onde o seu produto SQL o suporta (por exemplo CURRENT_TIMESTAMP em vez do servidor SQL getdate()), caso contrário prefere um código proprietário que facilmente mapeia para o código SQL padrão (por exemplo, o servidor SQL SUBSTRING() facilmente mapeia para o padrão SQL SUBSTRING() usando uma macro). Note que algumas funções fora do padrão SQL serão comuns para os produtos SQL (por exemplo, a maior parte/tudo terá uma função MOD() ou operador).

1

Author: onedaywhen, 2011-04-14 09:17:34

Eu construo aplicações web usando Alpha Five, que tem um recurso chamado "Portable SQL". Existem cerca de 200 "funções de portabilidade". Se eu usar uma função de portabilidade, ele irá automaticamente converter para SQL nativo para caber qualquer motor que eu acontecer a usar.

Então se eu escrever "selecione agora () dos clientes", agora() sendo uma função de portabilidade, essa sintaxe será automaticamente convertida para a linguagem nativa, dependendo do que eu acontecer de usar. Eles suportam 22 SQL diferentes busca.

DB2-seleccione a data actual como Expr1 do cliente
MYSQL-seleccione agora () como Expr1 do cliente
MSSQL-seleccione CURRENT_ timestamp como Expr1 do cliente
SYBASE-seleccione o getdate () como Expr1 do cliente
ODBC-SELECT {Fn Now ()} AS Expr1 FROM client

1

Author: user2625000, 2013-07-27 06:19:10

score 5 · Accepted Answer

O problema é que alguns DBMS até ignoram os padrões mais simples (por exemplo, como citar caracteres ou concatenação de cadeia de caracteres).

Assim, o seguinte (100% ANSI SQL) não é executado em todos os DBMS:

UPDATE some_table
    SET some_column = some_column || '_more_data';

E eu nem sequer estou a pensar em padrões SQL mais avançados, como expressões de tabela comuns recursivas (mesmo aquelas que suportam nem sempre cumprem) ou funções de janelas (algumas apenas implementam um subconjunto muito estreito, algumas não suportam todos Opcao).

Em relação ao DDL, há o problema com os tipos de dados. DATE não é o mesmo em todo o lado, assim como TIMESTAMP. Nem todos os DBMS têm um tipo BOOLEAN ou TIME Tipo.

Quando se trata de restrições ou domínios, você tem ainda mais diferenças.

Então, resumindo: a menos que você realmente, realmente realmente precisa ser independente do DBMS, não se preocupe com isso.

Tendo dito tudo isso: se você tem a escolha entre uma sintaxe proprietária e padrão Escolha a sintaxe padrão (OUTER JOIN vs (+) ou *=, decode vs CASE, nvl vs. coalesce e assim por diante).