Razones de las diferencias de SQL

Question

¿Por qué las distribuciones de SQL son tan poco estándar a pesar de que existe un estándar ANSI para SQL?¿Existen realmente tantas diferencias significativas en la forma en que funcionan las bases de datos SQL o son solo las dos bases de datos con las que he estado trabajando?¿MS-SQL y PostgreSQL?¿Por qué surgen estas diferencias?

Answer 1

Es una forma de "bloqueo sigiloso".Joel entra en gran detalle aquí:

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

Las empresas terminan vinculando su funcionalidad comercial a funcionalidades no estándar o extrañas y no compatibles en su implementación, lo que restringe su capacidad de pasar de su proveedor a un competidor.

Por otro lado, es bastante miope porque cualquiera con dos dedos de frente tenderá a abstraer las piezas patentadas, o a evitar el bloqueo por completo, si se vuelve demasiado atroz.

Answer 2

El estándar ANSI especifica sólo un conjunto limitado de comandos y tipos de datos.Una vez que se van más allá, los implementadores se quedan solos.Y algunos conceptos muy importantes no se especifican en absoluto, como las columnas de incremento automático.SQLite simplemente elige el primer entero no nulo, MySQL requiere AUTO INCREMENT, PostgreSQL usa secuencias, etc.¡Es un desastre, y eso sólo ocurre entre las bases de datos OSS!Intente lograr que Oracle, Microsoft e IBM decidan colectivamente sobre una funcionalidad complicada.

Answer 3

En primer lugar, no creo que las bases de datos sean como, por ejemplo, los navegadores o los sistemas operativos en términos de incompatibilidad.Cualquiera con unas pocas horas de formación puede empezar a realizar selecciones, inserciones, eliminaciones y actualizaciones en cualquier base de datos SQL.Mientras tanto, es difícil escribir HTML que se muestre de manera idéntica en todos los navegadores o escribir código de sistema para más de un sistema operativo.Generalmente, las diferencias en SQL están relacionadas con el rendimiento o características bastante esotéricas.La principal excepción parecen ser los formatos y funciones de fecha.

En segundo lugar, los desarrolladores de bases de datos generalmente están motivados para agregar características que diferencien su producto de los demás.Productos como Oracle, MS SQL Server y MySQL son ecosistemas vastos que rara vez se polinizan de forma cruzada en la práctica.En mi lugar de trabajo utilizamos Oracle y MySQL, pero probablemente podríamos cambiar a 100% Oracle en aproximadamente un día si lo necesitamos o lo deseamos.Así que me importan mucho los juguetes brillantes que Oracle nos brinda con cada lanzamiento, pero ni siquiera sé qué versión de MySQL estamos usando.En lo que a nosotros respecta, es posible que IBM, Microsoft, PostgreSQL y el resto no existan.Tener las funciones para conseguir y conservar clientes y usuarios es mucho más importante que la compatibilidad en el mundo de las bases de datos.(Supongo que ese es el giro positivo de la respuesta de "bloqueo").

En tercer lugar, existen razones legítimas para que diferentes empresas implementen SQL de manera diferente.Por ejemplo, Oracle tiene un sistema de múltiples versiones que permite lecturas consistentes muy rápidas y escalables.Otras bases de datos carecen de esa característica, pero generalmente son más rápidas al insertar filas y revertir transacciones.Esta es una diferencia fundamental en estos sistemas.No hace que uno sea mejor que el otro (al menos en el caso general), sólo diferente.No debería sorprendernos que el SQL encima de un motor de base de datos aproveche sus puntos fuertes e intente minimizar sus debilidades.De hecho, sería irresponsable por parte de los desarrolladores no hacer esto.

Answer 4

John:En realidad, el estándar cubre muchos temas, incluidas columnas de identidad, secuencias, desencadenantes, rutinas, upsert, etc.Pero, por supuesto, es posible que muchos de estos componentes estándar se hayan implementado después de las primeras implementaciones;y esta podría ser una razón por la cual el cumplimiento de los estándares SQL es algo bajo, en general.

Neal:De hecho, hay áreas en las que el estándar SQL está por delante de las implementaciones.Por ejemplo, sería bueno tener CREATE ASSERTION, pero hasta donde yo sé, ningún DBMS implementa aserciones todavía.

Personalmente, creo que la naturaleza cerrada de algunos estándares ISO (como el estándar SQL) es parte del problema:Cuando un estándar no está disponible en línea, es menos probable que sea conocido por los implementadores/planificadores, y muy pocos clientes solicitan su cumplimiento porque no saben qué pedir.

Answer 5

Es ciertamente un bloqueo efectivo, como dice 1800.Pero para ser justos con los proveedores de bases de datos, el estándar SQL siempre está poniéndose al día con los conjuntos de características de las bases de datos actuales.La mayoría de las bases de datos que tenemos hoy son de linajes bastante antiguos.Si rastreas Microsoft SQL Server hasta sus raíces, creo que encontrarás Ingres, una de las primeras bases de datos relacionales escritas en los años 70.Y Postgres fue escrito originalmente por algunas de las mismas personas en los años 80 como sucesor de Ingres.Oracle se remonta a mucho tiempo atrás y no estoy seguro de dónde entró MySQL.

La no portabilidad de la base de datos apesta, pero podría ser mucho peor.