¿Por qué no se adopta mejor el estándar SQL ANSI-92 que el ANSI-89?
En todas las empresas en las que he trabajado, descubrí que la gente todavía escribe sus consultas SQL en el estándar ANSI-89:
select a.id, b.id, b.address_1
from person a, address b
where a.id = b.id
en lugar del estándar ANSI-92:
select a.id, b.id, b.address_1
from person a
inner join address b
on a.id = b.id
Para una consulta extremadamente simple como esta, no hay una gran diferencia en la legibilidad, pero para consultas grandes encuentro que tener mis criterios de unión agrupados con una lista en la tabla hace que sea mucho más fácil ver dónde podría tener problemas en mi unión, y Déjame mantener todos mis filtros en mi cláusula WHERE. Sin mencionar que creo que las uniones externas son mucho más intuitivas que la sintaxis (+) en Oracle.
Mientras trato de evangelizar ANSI-92 entre las personas, ¿existen beneficios concretos de rendimiento al usar ANSI-92 sobre ANSI-89? Lo intentaría por mi cuenta, pero las configuraciones de Oracle que tenemos aquí no nos permiten usar EXPLAIN PLAN. No me gustaría que la gente intentara optimizar su código, ¿verdad?
Según "SQL Performance Tuning" de Peter Gulutzan y Trudy Pelzer, de las seis u ocho marcas de RDBMS que probaron, no hubo diferencia en la optimización o el rendimiento de las uniones de estilo SQL-89 versus SQL-92. Se puede suponer que la mayoría de los motores RDBMS transforman la sintaxis en una representación interna antes de optimizar o ejecutar la consulta, por lo que la sintaxis legible por humanos no hace ninguna diferencia.
También trato de evangelizar la sintaxis SQL-92. Dieciséis años después de su aprobación, ¡ya es hora de que la gente empiece a utilizarlo! Y todas las marcas de bases de datos SQL ahora lo admiten, por lo que no hay razón para seguir usando la (+)sintaxis no estándar de Oracle o *=la sintaxis de Microsoft/Sybase.
En cuanto a por qué es tan difícil romper con el hábito de SQL-89 en la comunidad de desarrolladores, sólo puedo suponer que hay una gran "base de la pirámide" de programadores que codifican copiando y pegando, utilizando ejemplos antiguos de libros, artículos de revistas, u otra base de código, y estas personas no aprenden nueva sintaxis de manera abstracta. Algunas personas coinciden con patrones y otras aprenden de memoria.
Sin embargo, poco a poco veo personas que utilizan la sintaxis SQL-92 con más frecuencia que antes. He estado respondiendo preguntas de SQL en línea desde 1994.
Bueno, el estándar ANSI092 incluye una sintaxis bastante atroz. Las uniones naturales son una y la cláusula USING es otra. En mi humilde opinión, la adición de una columna a una tabla no debería romper el código, pero una UNIÓN NATURAL se rompe de la manera más atroz. La "mejor" forma de romper es mediante un error de compilación. Por ejemplo, si SELECCIONA * en algún lugar, es posible que la adición de una columna no se pueda compilar. La siguiente mejor manera de fallar sería un error de tiempo de ejecución. Es peor porque tus usuarios pueden verlo, pero aun así te da una agradable advertencia de que has roto algo. Si usa ANSI92 y escribe consultas con uniones NATURALES, no se interrumpirá en el momento de la compilación ni en el tiempo de ejecución, la consulta de repente comenzará a producir resultados incorrectos. Este tipo de errores son insidiosos. Los informes salen mal y las divulgaciones potencialmente financieras son incorrectas.
Para aquellos que no están familiarizados con NATURAL Joins. Unen dos tablas en cada nombre de columna que existe en ambas tablas. Lo cual es realmente genial cuando tienes una clave de 4 columnas y estás cansado de escribirla. El problema surge cuando la Tabla1 tiene una columna preexistente llamada DESCRIPCIÓN y agregas una nueva columna a la Tabla2 llamada, oh no sé, algo inofensivo como, mmm, DESCRIPCIÓN y ahora estás uniendo las dos tablas en un VARCHAR2. (1000) campo que es de formato libre.
La cláusula USING puede generar una ambigüedad total además del problema descrito anteriormente. En otra publicación de SO , alguien mostró este SQL ANSI-92 y pidió ayuda para leerlo.
SELECT c.*
FROM companies AS c
JOIN users AS u USING(companyid)
JOIN jobs AS j USING(userid)
JOIN useraccounts AS us USING(userid)
WHERE j.jobid = 123
Esto es completamente ambiguo. Puse una columna de ID de usuario tanto en las tablas de empresas como de usuarios y no hay ninguna queja. ¿Qué pasa si la columna UserID en las empresas es el ID de la última persona que modificó esa fila?
Lo digo en serio. ¿Alguien puede explicar por qué era necesaria tal ambigüedad? ¿Por qué está integrado directamente en el estándar?
Creo que Bill tiene razón en que hay una gran base de desarrolladores que copian y pegan a través de la codificación. De hecho, puedo admitir que soy uno de ellos cuando se trata de ANSI-92. Todos los ejemplos que vi mostraban múltiples uniones anidadas entre paréntesis. Sinceramente, eso hace que, en el mejor de los casos, sea difícil seleccionar las tablas en SQL. Pero luego un evangelista de SQL92 explicó que eso en realidad forzaría una orden de unión. JESÚS... todos esos copiadores que he visto ahora están forzando un orden de unión, un trabajo que el 95% de las veces es mejor dejarlo en manos de los optimizadores, especialmente un copiador/pegador.
Tomalak acertó cuando dijo:
la gente no cambia a una nueva sintaxis sólo porque está ahí
Tiene que aportarme algo y no le veo ningún beneficio. Y si hay algo positivo, los negativos son un lastre demasiado grande para ignorarlo.
Dec 02 '2008 17:12
Se me ocurren algunas razones:
- la gente lo hace por costumbre
- la gente es perezosa y prefiere las combinaciones de "estilo antiguo" porque implican menos escritura
- Los principiantes a menudo tienen problemas para entender la sintaxis de unión SQL-92.
- la gente no cambia a una nueva sintaxis sólo porque está ahí
- la gente desconoce los beneficios que tiene la nueva sintaxis (si quiere llamarla así), principalmente que le permite filtrar una tabla antes de realizar una combinación externa, y no después cuando todo lo que tiene es la cláusula WHERE.
Por mi parte, hago todas mis uniones en la sintaxis SQL-92 y convierto el código donde puedo. Es la forma más limpia, legible y poderosa de hacerlo. Pero es difícil convencer a alguien de que use el nuevo estilo, cuando cree que le perjudica en términos de más trabajo de escritura sin cambiar el resultado de la consulta.
En respuesta a la publicación NATURAL JOIN y USING anterior.
¿POR QUÉ alguna vez verías la necesidad de usarlos? No estaban disponibles en ANSI-89 y se agregaron para ANSI-92 como lo que solo puedo ver como un atajo.
Nunca dejaría una unión al azar y siempre especificaría la tabla/alias y la identificación.
Para mí, el único camino a seguir es ANSI-92. Es más detallado y la sintaxis no es del agrado de los seguidores de ANSI-89, pero separa claramente sus UNIONES de su FILTRADO.
Primero déjame decirte que en SQL Server la sintaxis de unión externa (*=) no da resultados correctos todo el tiempo. Hay ocasiones en las que lo interpreta como una unión cruzada y no como una unión externa. Así que hay una buena razón para dejar de usarlo. Y esa sintaxis de unión externa es una característica obsoleta y no estará en la próxima versión de SQL Server después de SQL Server 2008. Aún podrá realizar las uniones internas, pero ¿por qué alguien querría hacerlo? No están claros y son mucho más difíciles de mantener. No es fácil saber qué es parte de la unión y qué es realmente la cláusula dónde.
Una razón por la que creo que no se debe utilizar la sintaxis antigua es que comprender las uniones y lo que hacen y no hacen es un paso crítico para cualquiera que escriba código SQL. No debe escribir ningún código SQL sin comprender a fondo las uniones. Si los entiendes bien, probablemente llegarás a la conclusión de que la sintaxis ANSI-92 es más clara y fácil de mantener. Nunca he conocido a un experto en SQL que no usara la sintaxis ANSI-92 con preferencia a la sintaxis antigua.
La mayoría de las personas que he conocido o con las que he tratado y que usan el código antiguo realmente no entienden las uniones y, por lo tanto, se meten en problemas al consultar la base de datos. Esta es mi experiencia personal, así que no digo que sea siempre cierta. Pero como especialista en datos, he tenido que arreglar demasiada basura a lo largo de los años como para no creerlo.
