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 un NATURAL JOIN 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, la adición de una columna podríafallar al compilar. La siguiente mejor forma de fallar sería un error de tiempo de ejecución. Es peor porque sus usuarios pueden verlo, pero aún así le da una buena advertencia de que ha roto algo. Si usa ANSI92 y escribe consultas con combinaciones NATURALES, no se interrumpirá en el tiempo de compilación y no se interrumpirá en el tiempo de ejecución, la consulta comenzará de repente a producir resultados incorrectos. Este tipo de errores son insidiosos. Los informes salen mal, la divulgación potencialmente financiera es incorrecta.
Para aquellos que no están familiarizados con NATURAL Joins. Unen dos tablas en cada nombre de columna que existe en ambas tablas. Lo que es realmente genial cuando tienes una clave de 4 columnas y estás harto de escribirla. El problema surge cuando Table1 tiene una columna preexistente llamada DESCRIPTION y agrega una nueva columna a Table2 llamada, oh, no sé, algo inofensivo como, mmm, DESCRIPTION y ahora está uniendo las dos tablas en un VARCHAR2 (1000) campo que es de forma libre.
La cláusula USING puede conducir a una ambigüedad total además del problema descrito anteriormente. En otra publicación de SO , alguien mostró este ANSI-92 SQL 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 en las tablas de empresas y usuarios y no hay ninguna queja. ¿Qué sucede si la columna UserID en las empresas es la ID de la última persona que modificó esa fila?
Lo digo en serio, ¿alguien puede explicar por qué era necesaria tanta 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. Cada ejemplo que vi mostraba múltiples combinaciones anidadas entre paréntesis. Honestamente, eso hace que elegir las tablas en el sql sea difícil en el mejor de los casos. Pero luego un evangilista de SQL92 explicó que en realidad forzaría una orden de unión. JESÚS ... todos esos correctores de copias que he visto ahora están forzando una orden de unión, un trabajo que es mejor dejar en el 95% del tiempo a los optimizadores especialmente una copia / empacadora.
Tomalak lo hizo bien cuando dijo:
la gente no cambia a una nueva sintaxis solo porque está ahí
Tiene que darme algo y no veo ninguna ventaja. Y si hay una ventaja, los aspectos negativos son un albatros demasiado grande para ser ignorado.