qué - sql concepts
¿Por qué ninguna base de datos es totalmente compatible con los estándares ANSI o ISO SQL? (12)
De acuerdo con el manual de HSQLDB, es el RDBMS más compatible con los estándares .
- Casi todas las características sintácticas de SQL-92 hasta nivel avanzado son compatibles
- SQL: núcleo 2008 y muchas características opcionales de este estándar
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 exigentes sobre qué partes de los estándares se adhieren, y por qué no han salido a la luz 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: lista de diferencias de implementación entre bases de datos comunes
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. Varias copias no oficiales 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", CJ Date, Hugh Darwen - Addison-Wesley).
En la industria del software, usted 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.
Entonces, no, ANSI SQL no cumple el mismo propósito que las normas ANSI en otras industrias. Pero sirve un propósito útil, no obstante.
En mi humilde opinión, los proveedores de DB impulsan los estándares ANSI SQL para incluir nuevas funciones y 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 está impulsado por 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) al esperar 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 "ANSI SQL" en los últimos años. (SQL Server con SELECT FROM INFORMATION_SCHEMA y ANSI de Oracle se une realmente a las uniones nativas en la CBO)
Hace unos años, una de las peores industrias en cuanto a tuberías y conectores compatibles entre sí era el equipo de extinción de 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 retrocedes lo suficiente, puedes 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 se producen 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 del estándar SQL aún podría 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.
La mayoría de ellos son bastante obedientes. 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.
La verdadera razón: la mayoría de los "desarrolladores" son codificadores centrados en el cliente y, por lo tanto, ni comprenden 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.
Las empresas generalmente tienden a usar un proveedor para evitar tener una jungla de sistemas diferentes y posiblemente incompatibles para respaldar. 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.
No conozco la historia de ANSI SQL específicamente. 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.
Probablemente porque la conformidad de los estándares es de baja prioridad para los compradores del sistema de bases de datos. Están más interesados en:
- compatibilidad con lo que ya tienen
- actuación
- precio
- Soporte del sistema operativo
por nombrar solo algunos factores.
Lo mismo es cierto para los lenguajes de programación: muy pocos compiladores (si los hay) soportan cada característica 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 ofrecen soporte estándar a bordo. Por ejemplo, la mayoría de los proveedores admiten más o menos todo 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.
Ver el artículo " IS SQL A REAL STANDARD ANYMORE?" para una discusión sobre los problemas actuales (2005) del estándar SQL.
Mimer SQL tiene un gran soporte de estándares, pero es bastante desconocido. Está en producción en varios sitios grandes, principalmente en Suecia. Pero creo que muchos sitios están migrando a otros.
Declaraciones detalladas de soporte:
- SQL-99
- SQL-2003
- PSM
- Activadores y funciones de la base de datos según SQL: 1999
- Soporte binario y de caracteres grandes OBjects (BLOB / CLOB / NCLOB) según SQL: 1999
- Transacciones de múltiples bases de datos (confirmación en dos fases) conforme al estándar XA del Grupo abierto
- Soporte para Java ME CDC Foundation Profile y Java ME CLDC / MIDP