¿Por qué ninguna base de datos es totalmente compatible con los estándares ANSI o ISO SQL?

Question

Si estuviera diseñando una refinería de petróleo, no esperaría que los materiales de diferentes proveedores no cumplan con los estándares publicados en formas sutiles pero importantes. Las tuberías, válvulas y otros componentes de un proveedor vendrían con bridas y espesores de pared según las normas ANSI, al igual que las mismas partes de cualquier otro proveedor. La interoperabilidad y la seguridad del sistema están, por lo tanto, aseguradas.

¿Por qué entonces las bases de datos comunes son tan selectivas sobre qué partes de los estándares se adhieren y por qué no han surgido sistemas 100% compatibles con los estándares? ¿Los estándares están "rotos", carecen de alcance o son demasiado difíciles de diseñar?

Llevando esto a la conclusión; ¿Cuál es el objetivo de los estándares de definición ANSI (o ISO) para SQL?

Editar: List of implementation differences between common databases

Answer 1

En la industria del software tiene algunos estándares que realmente son estándares, es decir, los productos que no los cumplen simplemente no funcionan. Las especificaciones de archivo caen en esa categoría. Pero también tiene "estándares" que son más como pautas: pueden definirse como estándares con definiciones punto a punto, pero rutinariamente implementados solo parcialmente o con diferencias significativas. El desarrollo web está lleno de tales "estándares", como HTML, CSS y "ECMAScript", donde diferentes proveedores (es decir, navegadores web) implementan los estándares de manera diferente.

La variación causa dolores de cabeza, pero la estandarización aún proporciona beneficios. Imagínese si no hubiera ningún estándar HTML en absoluto y cada navegador utilizara su propio lenguaje de marcado. Del mismo modo, imagínese si no existiera un estándar SQL y cada proveedor de base de datos utilizara su propio lenguaje de consulta completamente patentado. Habría mucho más bloqueo de proveedores, y los desarrolladores tendrían más dificultades para trabajar con más de un producto.

Por lo tanto, no, ANSI SQL no cumple la misma función que las normas ANSI en otras industrias. Pero sirve un propósito útil, no obstante.

Answer 2

Probablemente porque los estándares de conformidad es de una baja prioridad a los compradores del sistema de base de datos. Ellos están más interesados ​​en:

• compatibilidad con lo que ya tienen
• rendimiento
• precio
• compatibilidad con sistemas operativos

, por nombrar sólo algunos factores.

Lo mismo se aplica a los lenguajes de programación: muy pocos compiladores (si es que los hay) admiten todas las características de los estándares actuales ANSI C y C++.

En cuanto a por qué molestarse con el estándar, la mayoría de los proveedores finalmente llevan el soporte estándar a bordo. Por ejemplo, la mayoría de los proveedores admiten más o menos todos los SQL89. Esto le permite al proveedor marcar una casilla de verificación (relativamente poco importante) en su hoja de especificaciones y también permite que personas como yo, que están interesadas en escribir códigos portátiles, lo hagan, aunque tengan que renunciar a muchas cosas.

Answer 3

No conozco específicamente el historial de ANSI SQL. Pero parece que muchas veces en el desarrollo de software, los estándares se escriben después de que los principales actores ya hayan implementado sus propias versiones propietarias de las cosas. Una vez que una empresa se invierte en su propia forma de hacer las cosas, es realmente difícil justificar el cambio o la eliminación de las características en las que las personas confían solo para adherirse a un estándar. Los estándares web son un ejemplo principal de este fenómeno.

Answer 4

En mi humilde opinión, los proveedores de DB impulsan los estándares ANSI SQL para incluir nuevas funciones & construcciones dentro de su campo mucho más que ANSI diciéndoles a los proveedores de DB la "única y verdadera manera".

El mercado de DB se basa en características, escalabilidad y costo. No es una prioridad comercial renunciar y retrasar una ventaja técnica (es decir, partición, pivote, UPSERT, replicación) esperando que ANSI ratifique la sintaxis. En el momento en que se ha hecho, ya hay una instalación significativa de la sintaxis patentada.

Dicho esto, la mayoría de los proveedores de DB han mejorado enormemente su soporte principal "ANSI SQL" en los últimos años. (SQL Server con SELECT FROM INFORMATION_SCHEMA y Oracle ANSI se une realmente a las uniones nativas bajo CBO)

Answer 5

Hace unos años, una de las peores industrias en cuanto a tuberías y conectores compatibles era el equipo de lucha contra incendios.Había literalmente docenas de mangueras mutuamente incompatibles para las conexiones de la bomba. Cuando la ayuda mutua se volvió común entre los bomberos, tuvieron que traer docenas de adaptadores para poder interoperar con su equipo.

El 11 de septiembre, tanto la policía como los bomberos tenían redes inalámbricas privadas para intercomunicarse entre su gente. ¿Pero adivina que? Los dos sistemas no eran mutuamente compatibles. Entonces hubo demoras innecesarias en la comunicación de información de un tipo de servidor de seguridad pública a otro.

Si retrocede lo suficiente, puede encontrar un momento en la ciudad de Nueva York donde aproximadamente la mitad de la red eléctrica era DC, favorecida por Edison, y la otra mitad era AC, favorecida por Westinghouse.

Las normas a veces surgen por sí mismas y se llaman estándares de facto. Más comúnmente, los estándares tienen que ser establecidos por un cuerpo específicamente habilitado para hacerlo realidad. En cuanto a los estándares SQL, algunos de los proveedores más grandes son anteriores al estándar. Para cumplir con el estándar, tendrían que invertir en gastos de ingeniería que no benefician a su base de clientes existente. Peor aún, podrían terminar siendo incompatibles con su propio producto anterior.

El cumplimiento total con el estándar SQL aún puede ocurrir, pero es poco probable. Incluso si lo hace, hay un tiempo de retraso entre la evolución de un nuevo estándar SQL y su cumplimiento.

Answer 6

La mayoría de ellos son bastante compatibles. Pero estas son las malas noticias, la OMI: los estándares generan mediocridad. Los vendedores quieren que se bloquee en sus extensiones, y a menudo hay buenas razones para hacer cosas no estándar. De manera realista, ¿qué probabilidades hay de que descargue Oracle para SQL Server, o viceversa? A menos que construya un producto que sus clientes puedan usar contra otras bases de datos, es poco probable que usted como empresa cambie sus DB. Muy doloroso.

Answer 7

La verdadera razón: la mayoría de los "desarrolladores" son codificadores centrados en el cliente, y por lo tanto, ni entienden ni se preocupan por las 12 reglas del Dr. Codd. Esta es la razón por la cual MySql, que no es una base de datos relacional de ninguna manera significativa, se ve con frecuencia en el desarrollo de webKiddie. Dichos desarrolladores solo desean un análisis rudimentario SELECT, UPDATE, DELETE. Evitan restricciones de cualquier tipo, prefiriendo "hacerlo en la aplicación". Las aplicaciones reaccionarias de los años 60 son lo que obtienes.

Answer 8

De hecho, el estándar ANSI SQL no se sigue a menudo. Simplemente lea SO: la mayoría de los subprocesos de SQL nunca se refieren al estándar, mientras que, por ejemplo, las discusiones sobre los protocolos de red a menudo incluyen la cita, el capítulo y el verso reales del RFC pertinente.

Siempre sospeché que una de las razones es el hecho de que el estándar SQL no se puede distribuir libremente. Simplemente obtenerlo no es trivial. Varios unofficial copies flotan alrededor.)

Otra razón es que es un texto muy complicado y poco organizado. Utiliza un vocabulario extraño (como "authID" en lugar de "usuario"). Necesita libros solo para comprender el estándar ("Una guía para el estándar SQL", C.J. Date, Hugh Darwen - Addison-Wesley).

Answer 9

Mimer SQL tiene soporte para grandes estándares, sin embargo es bastante desconocido. Está en producción en varios sitios grandes, principalmente en Suecia. Pero creo que muchos sitios están migrando a otros.

statments de apoyo detalladas:

• SQL-99
• SQL-2003
• PSM
• trigger y funciones de acuerdo con SQL: 1999
• binario y Carácter objetos grandes (BLOB/CLOB/NCLOB) soporte según SQL: 1999
• Transacciones de múltiples bases de datos (confirmación en dos fases)) Conforme a Open XA-estándar
• apoyo del Grupo para la Fundación de Java ME CDC perfil y Java ME CLDC/MIDP

Answer 10

Véase el artículo "IS SQL A REAL STANDARD ANYMORE?" para una discusión sobre las actuales (2005) temas de la norma SQL.

Answer 11

Las empresas generalmente tienden a utilizar un solo proveedor para evitar tener una jungla de sistemas diferentes y posiblemente incompatibles. También es mucho más barato capacitar a los desarrolladores/ingenieros de sistemas en el uso de las herramientas de un proveedor de base de datos que en 3 conjuntos diferentes de herramientas. Más adelante, esta empresa puede crecer lo suficiente como para comprar algunos de sus competidores. Esto significaría otro conjunto de herramientas completamente diferente que tendría que administrar, integrar, etc.

Eso es mucho trabajo.

Imagine que en lugar de eso, tiene una capa de portabilidad para que realmente no le importe lo que hay debajo. Eso sería mucho mejor.

Answer 12

De acuerdo con el manual HSQLDB, it is the most standards compliant RDBMS.

• Casi todas las características sintácticas de SQL-92 hasta el nivel avanzado son compatibles
• SQL: 2008 núcleo y muchas características opcionales de esta norma