Razões para diferenças de SQL

Question

Por que as distribuições SQL são tão fora do padrão, apesar de existir um padrão ANSI para SQL?Existem realmente muitas diferenças significativas na forma como os bancos de dados SQL funcionam ou são apenas os dois bancos de dados com os quais tenho trabalhado:MS-SQL e PostgreSQL?Por que surgem essas diferenças?

Answer 1

É uma forma de "aprisionamento furtivo".Joel entra em detalhes aqui:

• http://www.joelonsoftware.com/articles/fog0000000056.html
• http://www.joelonsoftware.com/articles/fog0000000052.html

As empresas acabam vinculando suas funcionalidades de negócios a funcionalidades não padronizadas ou estranhas e sem suporte em sua implementação, o que restringe sua capacidade de se afastar de seu fornecedor para um concorrente.

Por outro lado, é bastante míope porque qualquer pessoa com meio cérebro tenderá a abstrair as peças proprietárias, ou a evitar completamente o aprisionamento, se este se tornar demasiado flagrante.

Answer 2

O padrão ANSI especifica apenas um conjunto limitado de comandos e tipos de dados.Depois de ir além disso, os implementadores estarão por conta própria.E alguns conceitos muito importantes não são especificados, como colunas de incremento automático.SQLite apenas escolhe o primeiro número inteiro não nulo, o MySQL requer AUTO INCREMENT, PostgreSQL usa sequências, etc.É uma bagunça, e isso só acontece entre os bancos de dados OSS!Tente fazer com que a Oracle, a Microsoft e a IBM decidam coletivamente sobre uma funcionalidade complicada.

Answer 3

Primeiro, não considero os bancos de dados como, digamos, navegadores ou sistemas operacionais em termos de incompatibilidade.Qualquer pessoa com algumas horas de treinamento pode começar a fazer seleções, inserções, exclusões e atualizações em qualquer banco de dados SQL.Enquanto isso, é difícil escrever HTML que seja renderizado de forma idêntica em todos os navegadores ou escrever código de sistema para mais de um sistema operacional.Geralmente, as diferenças no SQL estão relacionadas ao desempenho ou a recursos bastante esotéricos.A principal exceção parece ser os formatos e funções de data.

Segundo, os desenvolvedores de banco de dados geralmente são motivados a adicionar recursos que diferenciem seu produto de todos os outros.Produtos como Oracle, MS SQL Server e MySQL são vastos ecossistemas que raramente realizam polinização cruzada na prática.No meu local de trabalho, usamos Oracle e MySQL, mas provavelmente poderíamos mudar para 100% Oracle em cerca de um dia, se necessário ou desejado.Então, eu me importo muito com os brinquedos brilhantes que a Oracle nos dá a cada lançamento, mas nem sei qual versão do MySQL estamos usando.IBM, Microsoft, PostgreSQL e o resto podem muito bem não existir, no que nos diz respeito.Ter os recursos para obter e manter clientes e usuários é muito mais importante do que a compatibilidade no mundo dos bancos de dados.(Essa é a versão positiva da resposta "aprisionada", suponho.)

Terceiro, existem razões legítimas para diferentes empresas implementarem o SQL de maneira diferente.Por exemplo, a Oracle possui um sistema multi-versionamento que permite leituras consistentes muito rápidas e escaláveis.Outros bancos de dados não possuem esse recurso, mas geralmente são mais rápidos na inserção de linhas e na reversão de transações.Esta é uma diferença fundamental nesses sistemas.Isso não torna um melhor que o outro (pelo menos no caso geral), apenas diferente.Não devemos nos surpreender se o SQL no topo de um mecanismo de banco de dados aproveitar seus pontos fortes e tentar minimizar seus pontos fracos.Na verdade, seria irresponsável da parte dos desenvolvedores não fazer isso.

Answer 4

John:Na verdade, o padrão cobre muitos assuntos, incluindo colunas de identidade, sequências, gatilhos, rotinas, upsert, etc.Mas é claro que muitos desses componentes de padrões podem ter sido implementados depois das primeiras implementações;e esse pode ser o motivo pelo qual a conformidade com os padrões SQL é um tanto baixa, em geral.

Neal:Na verdade, existem áreas onde o padrão SQL está à frente das implementações.Por exemplo, seria bom ter CREATE ASSERTION, mas até onde eu sei, nenhum SGBD implementa asserções ainda.

Pessoalmente, acredito que a natureza fechada de alguns padrões ISO (como o padrão SQL) é parte do problema:Quando um padrão não está prontamente disponível on-line, é menos provável que ele seja conhecido pelos implementadores/planejadores, e poucos clientes solicitam conformidade porque não sabem o que pedir.

Answer 5

É certamente um aprisionamento eficaz, como diz 1800.Mas, para ser justo com os fornecedores de bancos de dados, o padrão SQL está sempre tentando acompanhar os conjuntos de recursos dos bancos de dados atuais.A maioria dos bancos de dados que temos hoje são de linhagens bastante antigas.Se você rastrear o Microsoft SQL Server até suas raízes, acho que encontrará o Ingres – um dos primeiros bancos de dados relacionais escritos nos anos 70.E o Postgres foi originalmente escrito por algumas das mesmas pessoas nos anos 80 como sucessor do Ingres.A Oracle existe há muito tempo e não tenho certeza de onde o MySQL entrou.

A não portabilidade do banco de dados é uma droga, mas poderia ser muito pior.