¿Por qué las distribuciones SQL son tan no 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?Razones para las diferencias SQL
Es una forma de "Stealth lock-in". Joel entra en gran detalle aquí:
empresas terminan atando su funcionalidad empresarial a una función no soportada no estándar o extraño en su aplicación, lo que limita su capacidad de alejarse de su proveedor a un competidor.
Por otro lado, es bastante miope porque cualquier persona con medio cerebro tenderá a abstraer las piezas patentadas, o evitar el bloqueo por completo, si se pone demasiado atroz.
El estándar ANSI especifica solo un conjunto limitado de comandos y tipos de datos. Una vez que va más allá de ellos, los implementadores están 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 es solo entre las bases de datos de OSS! Intente que Oracle, Microsoft e IBM decidan colectivamente sobre un poco de funcionalidad.
Sin duda es un bloqueo efectivo, como dice 1800. Pero para ser justos con los proveedores de la base de datos, el estándar SQL siempre está jugando al ponerse 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 a 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 va mucho más atrás, y no estoy seguro de dónde entró MySQL.
La no portabilidad de la base de datos es mala, pero podría ser mucho peor.
John: El estándar realmente cubre muchos temas, incluyendo columnas de identidad, secuencias, desencadenadores, rutinas, upsert, etc. Pero, por supuesto, muchos de estos componentes de estándares pueden haberse implementado más tarde que las primeras implementaciones; y esta podría ser una razón por la cual el cumplimiento de estándares SQL es algo bajo, en general.
Neall: En realidad, hay áreas donde 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 los implementadores/planificadores lo conozcan, y también pocos clientes piden cumplimiento porque no saben qué pedir.
En primer lugar, no considero que las bases de datos sean, por ejemplo, navegadores o sistemas operativos en términos de incompatibilidad. Cualquier persona con unas horas de entrenamiento puede comenzar a seleccionar, insertar, eliminar y actualizar en cualquier base de datos SQL. Mientras tanto, es difícil escribir HTML que se representa de forma idéntica en cada navegador o escribir código de sistema para más de un sistema operativo. En general, las diferencias en SQL están relacionadas con el rendimiento o con características bastante esotéricas. La principal excepción parece ser formatos de fecha y funciones.
En segundo lugar, los desarrolladores de bases de datos en general están motivados para agregar características que diferencien su producto de los demás. Productos como Oracle, MS SQL Server y MySQL son vastos ecosistemas que rara vez se polinizan cruzadamente en la práctica. En mi lugar de trabajo, usamos Oracle y MySQL, pero probablemente podríamos cambiar al 100% de Oracle en aproximadamente un día si es necesario o deseado. Así que me preocupan mucho los juguetes brillantes que Oracle nos ofrece en cada lanzamiento, pero ni siquiera sé qué versión de MySQL estamos usando. IBM, Microsoft, PostgreSQL y el resto podrían no existir en lo que a nosotros respecta. Tener las características para obtener y mantener clientes y usuarios es mucho más importante que la compatibilidad en el mundo de la base de datos. (Ese es el giro positivo en la respuesta de "bloqueo", supongo.)
En tercer lugar, existen razones legítimas para que diferentes compañías 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 insertando filas y retrotrayendo transacciones. Esta es una diferencia fundamental en estos sistemas. No lo hace uno mejor que el otro (al menos en el caso general), simplemente diferente. Uno no debería sorprenderse si SQL ontop de un motor de base de datos aprovecha sus fortalezas e intenta minimizar sus debilidades. De hecho, sería irresponsable de los desarrolladores no hacer esto.
Otra razón es la compatibilidad con versiones anteriores que, combinadas con características agregadas en los productos iniciales pero no en el estándar o agregadas posteriormente, da como resultado implementaciones diferentes que son muy difíciles de eliminar más adelante (ejemplo 'CROSS APPLY' en SQL Server que es similar a el (más cercano al estándar) 'LATERAL' en DB2 y Postgres,' CONNECT BY' en Oracle, hicieron años antes de agregar CTE recursivos, 'LIMIT' /' TOP'/'FETCH FIRST' en varios dbms, etc.). –