tipo - Razones para las diferencias de SQL

sql server v17 (5)

Ciertamente 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.

¿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 solo son las dos bases de datos con las que he estado trabajando: MS-SQL y PostgreSQL? ¿Por qué surgen estas diferencias?

Es una forma de "Stealth lock-in". Joel entra en gran detalle aquí:

Las empresas terminan vinculando la funcionalidad de su negocio a funcionalidades no estándar o extrañas no admitidas en su implementación, esto restringe su capacidad de alejarse de su proveedor a un competidor.

Por otro lado, es bastante corto de miras porque cualquier persona con medio cerebro tenderá a abstraer las piezas patentadas, o evitar el bloqueo por completo, si es demasiado atroz.

John: El estándar en realidad cubre muchos temas, incluyendo columnas de identidad, secuencias, disparadores, 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 muy pocos clientes piden cumplimiento porque no saben qué pedir.

Primero, no creo 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 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 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. (Esa es la vuelta positiva 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.

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 solo elige el primer entero no nulo, MySQL requiere AUTO INCREMENT , PostgreSQL utiliza 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.