sirve - ¿Por qué el estándar SQL ANSI-92 no se adopta mejor que ANSI-89?

sql-86 (16)

En cada compañía en la que he trabajado, he encontrado que las personas aún escriben 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 mi criterio de unión agrupado con el listado de la tabla hace que sea mucho más fácil ver dónde podría haber problemas en mi unión, y vamos a mantener todo mi filtrado en mi cláusula WHERE. Sin mencionar que siento que las uniones externas son mucho más intuitivas que la sintaxis (+) en Oracle.

Al tratar de evangelizar ANSI-92 a las personas, ¿hay algún beneficio concreto en el desempeño al usar ANSI-92 sobre ANSI-89? Lo probaría solo, pero las configuraciones de Oracle que tenemos aquí no nos permiten usar EXPLAIN PLAN. No querríamos que las personas intenten optimizar su código, ¿o sí?

1) Forma estándar de escribir OUTER JOIN, versus * = o (+) =

2) UNIÓN NATURAL

3) Depende del motor de la base de datos, las tendencias ANSI-92 serán más óptimas.

4) optimización manual:

Digamos que tenemos la siguiente sintaxis (ANSI-89):

(1)select * from TABLE_OFFICES to,BIG_TABLE_USERS btu where to.iduser=tbu.iduser and to.idoffice=1

Podría escribirse como:

(2)select * from TABLE_OFFICES to inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser where to.idoffice=1

Pero también como:

(3)select * from TABLE_OFFICES to inner join BIG_TABLE_USERS btu on to.iduser=tbu.iduser and to.idoffice=1

Todos ellos (1), (2), (3) devuelven el mismo resultado; sin embargo, están optimizados de forma diferente, depende del motor de la base de datos, pero la mayoría de ellos lo hacen:

(1) depende del motor de base de datos decidir la optimización.
(2) une ambas tablas y luego hace el filtro por oficina.
(3) filtra los BIG_TABLE_USERS utilizando la idoffice y luego une ambas tablas.

5) Las consultas más largas son menos complicadas.

Algunas razones vienen a la mente:

la gente lo hace por costumbre
las personas son flojas y prefieren el "estilo antiguo" porque implica menos tipeo
los principiantes a menudo tienen sus problemas envolviendo sus cabezas alrededor de la sintaxis de unión SQL-92
las personas no cambian a una nueva sintaxis solo porque está ahí
la gente desconoce los beneficios que la nueva sintaxis (si así lo quiere llamar) tiene, principalmente, que le permite filtrar una tabla antes de hacer una combinación externa, y no después cuando todo lo que tiene es la cláusula WHERE.

Por mi parte, hago todas las combinaciones en la sintaxis SQL-92, y convierto el código donde puedo. Es la manera más limpia, más legible y poderosa de hacerlo. Pero es difícil convencer a alguien para que use el nuevo estilo, cuando piensan que les duele en términos de más trabajo de tipeo sin cambiar el resultado de la consulta.

Aquí hay algunos puntos que comparan SQL-89 y SQL-92 y aclaran algunos conceptos erróneos en otras respuestas.

NATURAL JOINS son una idea horrible. Están implícitos y requieren metainformación sobre la tabla. Nada sobre SQL-92 requiere su uso así que simplemente ignórelos . No son relevantes para esta discusión.
USING es una gran idea, tiene dos efectos:
1. Produce solo una columna en el conjunto de resultados de una equijoin.
2. Se aplica una convención sana y sensata. En SQL-89, tenía personas escribiendo el id la columna en ambas tablas. Después de unirse a las tablas, esto se vuelve ambiguo y requiere un alias explícito. Además, las id en la unión casi con certeza tenían datos diferentes. Si se une de persona a empresa, ahora tiene que person_id una id a person_id y una id a company_id , sin la cual la unión produciría dos columnas ambiguas. El uso de un identificador único global para la clave sustituta de la tabla es la convención de las recompensas estándar con USING .
La sintaxis de SQL-89 es una CROSS JOIN implícita. Una CROSS JOIN no reduce el conjunto, sino que lo crece implícitamente. FROM T1,T2 es lo mismo que FROM T1 CROSS JOIN T2 , que produce una unión cartesiana que generalmente no es la que desea. Tener la selectividad para reducir eso eliminado a un distante WHERE condicional significa que es más probable que cometa errores durante el diseño.
SQL-89 y SQL-92 explícitos JOIN s tienen diferente precedencia. JOIN tiene una precedencia más alta. Peor aún, algunas bases de datos como MySQL obtuvieron este error durante mucho tiempo. . Así que mezclar los dos estilos es una mala idea, y el estilo mucho más popular hoy en día es el estilo SQL-92.

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 debe romper el código, pero una unión NATURAL se rompe de la manera más atroz. La "mejor" forma de romper es por error de compilación. Por ejemplo, si SELECCIONA * en algún lugar, la adición de una columna podría no compilarse. La siguiente mejor manera 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 uniones NATURALES, no se romperá en tiempo de compilación y no se romperá 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, 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 cual es genial cuando tienes una clave de 4 columnas y estás cansado de escribirla. El problema aparece cuando Table1 tiene una columna preexistente llamada DESCRIPTION y usted 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 generar una ambigüedad total además del problema descrito anteriormente. En otra publicación 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 UserID tanto en las compañías como en las tablas 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é esa ambigüedad era necesaria? ¿Por qué está construido directamente en el estándar?

Creo que Bill está en lo cierto al decir que hay una gran base de desarrolladores que copian / pegan a través de la codificación. De hecho, puedo admitir que soy uno cuando se trata de ANSI-92. Todos los ejemplos que vi mostraron múltiples uniones anidadas entre paréntesis. La honestidad, eso hace que elegir las mesas en el sql sea difícil en el mejor de los casos. Pero luego un evangilista SQL92 explicó que en realidad forzaría una orden de unión. JESÚS ... todos esos pasadores de Copia que he visto ahora están forzando una orden de unión, un trabajo que es mejor el 95% del tiempo para los optimizadores, especialmente una copia / pasteurización.

Tomalak lo hizo bien cuando dijo:

las personas no cambian a una nueva sintaxis solo porque está ahí

Tiene que darme algo y no veo una ventaja. Y si hay un lado positivo, los negativos son un albatros demasiado grande para ser ignorado.

En respuesta a la publicación NATURAL JOIN y USING anterior.

¿POR QUÉ vería alguna vez la necesidad de usar estos? No estaban disponibles en ANSI-89 y se agregaron para ANSI-92 como lo que solo puedo ver como un acceso directo.

Nunca dejaría una combinació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 cuidadosamente tus UNIONES de tu FILTRADO.

Inercia y practicidad.

ANSI-92 SQL es como el mecanografiado al tacto. De alguna forma teórica, podría mejorar todo un día, pero ahora puedo escribir mucho más rápido mirando las teclas con cuatro dedos. Tendría que retroceder para avanzar, sin ninguna garantía de que alguna vez se produzca un pago.

Escribir SQL es aproximadamente el 10% de mi trabajo. Si necesito ANSI-92 SQL para resolver un problema que ANSI-89 SQL no puede resolver, entonces lo usaré. (Lo uso en Access, de hecho.) Si usarlo todo el tiempo me ayudaría a resolver mis problemas existentes mucho más rápido, me gustaría dedicar el tiempo para asimilarlo. Pero puedo sacar ANSI-89 SQL sin pensar en la sintaxis. Me pagan para resolver problemas. Pensar en la sintaxis de SQL es una pérdida de mi tiempo y del dinero de mi empleador.

Algún día, el joven Grasshopper, defenderá el uso de la sintaxis ANSI-92 SQL frente a los jóvenes quejarse de que debería usar SQL3 (o lo que sea). Y luego lo comprenderás. :-)

Me enseñaron ANSI-89 en la escuela y trabajé en la industria durante algunos años. Luego dejé el fabuloso mundo de DBMS durante 8 años. Pero luego volví y me enseñaron estas nuevas cosas de ANSI 92. Aprendí la sintaxis Join On y ahora enseño SQL y recomiendo la nueva sintaxis JOIN ON.

Pero la desventaja que veo es que las subconsultas correlacionadas no parecen tener sentido a la luz de las uniones ANSI 92. Cuando la información de unión se incluyó en WHERE y las subconsultas correlacionadas se "unieron" en DONDE todo parecía correcto y consistente. En los criterios de unión de tabla ANSI 92 no está en WHERE y la subconsulta "join" es, la sintaxis parece inconsistente. Por otro lado, tratar de "arreglar" esta inconsistencia probablemente solo empeore las cosas.

No puedo hablar por todas las escuelas, pero en mi universidad cuando estábamos haciendo el módulo SQL de nuestro curso, no enseñaban ANSI-92, sino que enseñaban ANSI-89, en un viejo sistema VAX. No estuve expuesta a ANSI-92 hasta que comencé a buscar en Access habiendo creado algunas consultas utilizando el diseñador de consultas y luego profundizando en el código SQL. Al darme cuenta de que no tenía idea de cómo se completaban las uniones, o las implicaciones de la sintaxis, comencé a cavar más profundo para poder entenderlo.

Dado que la documentación disponible no es exactamente intuitiva en muchos casos, y que las personas tienden a apegarse a lo que saben y en muchos casos no se esfuerzan por aprender más de lo que necesitan para hacer su trabajo, es fácil de ver por qué la adopción lleva tanto tiempo.

Por supuesto, están aquellos evangelistas técnicos a los que les gusta jugar y entender, y tienden a ser aquellos que adoptan los principios "más nuevos" y tratan de convertir el resto.

Curiosamente, me parece que muchos programadores salen de la escuela y dejan de avanzar; pensando que porque esto es lo que les enseñaron, así es como se hace. No es hasta que te quites las pestañas que te das cuenta que la escuela solo tenía la intención de enseñarte lo básico y darte la suficiente comprensión para aprender el resto y que realmente apenas arañaste la superficie de lo que hay que saber; ahora es tu trabajo continuar ese camino.

Por supuesto, esa es solo mi opinión basada en mi experiencia.

No sé la respuesta con seguridad ... esta es una guerra religiosa (aunque en menor grado que Mac-PC u otros)

Supongo que hasta hace muy poco tiempo, Oracle (y tal vez otros proveedores también) no adoptaron el estándar ANSI-92 (creo que fue en Oracle v9, aproximadamente) y, por lo tanto, para DBAs / Db Developers que trabajan en compañías que seguían usando estas versiones (o el código deseado para ser portable en los servidores que podrían estar usando estas versiones, tenían que seguir el viejo estándar ...

Realmente es una pena, porque la nueva sintaxis de unión es mucho más legible, y la sintaxis anterior genera resultados incorrectos (incorrectos) en varios escenarios bien documentados.

Específicamente, se une al exterior cuando hay predicados de filtrado condicional en columnas relacionadas que no se unen desde la tabla en el lado "exterior" de la unión.

Oracle no implementa ANSI-92 en absoluto. He tenido varios problemas, sobre todo porque las tablas de datos en Oracle Apps están muy bien dotadas de columnas. Si el número de columnas en sus uniones supera las 1050 columnas (lo cual es muy fácil de hacer en Aplicaciones), entonces obtendrá este error espurio que no tiene absolutamente ningún sentido lógico:

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

Volver a escribir la consulta para usar la sintaxis de unión de estilo antiguo hace que el problema desaparezca, lo que parece apuntar directamente con la implementación de las uniones ANSI-92.

Hasta que encontré este problema, fui un firme promotor de ASNI-92, debido a los beneficios en la reducción de la posibilidad de una combinación cruzada accidental, que es demasiado fácil de hacer con la sintaxis antigua.

Ahora, sin embargo, me resulta mucho más difícil insistir en ello. Señalan la mala implementación de Oracle y dicen: "Lo haremos a nuestra manera, gracias".

Primero déjeme decir que en SQL Server la sintaxis de unión externa (* =) no da resultados correctos todo el tiempo. Hay momentos en que lo interpreta como una combinación cruzada y no como una combinación externa. Entonces, 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á hacer las uniones internas, pero ¿por qué alguien querría hacerlo? No son claros y mucho más difíciles de mantener. No se sabe fácilmente qué es parte de la unión y cuál es realmente la cláusula where.

Una de las razones por las que creo que no debería usar la sintaxis anterior es que entender las uniones y lo que hacen y lo que no hacen es un paso crítico para cualquiera que escriba código SQL. No debe escribir ningún código SQL sin entender las combinaciones a fondo. Si los entiende bien, probablemente llegue a la conclusión de que la sintaxis ANSI-92 es más clara y fácil de mantener. Nunca conocí a un experto en SQL que no usara la sintaxis ANSI-92 con preferencia a la sintaxis anterior.

La mayoría de las personas con las que he conocido o tratado y que usan el código anterior realmente no entienden las uniones y se meten en problemas al consultar la base de datos. Esta es mi experiencia personal, así que no estoy diciendo que sea siempre verdad. Pero como especialista en datos, he tenido que arreglar demasiado de esta basura a través de los años para no creerlo.

Puedo responder desde el punto de vista de un desarrollador medio, sabiendo exactamente lo suficiente SQL para entender ambas sintaxis, pero aún buscando en Google la sintaxis exacta de la inserción cada vez que lo necesito ... :-P (No hago SQL todo el día , simplemente arreglando algunos problemas de vez en cuando.)

Bueno, en realidad, creo que la primera forma es más intuitiva, sin aparente jerarquía entre las dos tablas. El hecho de que aprendí SQL con libros posiblemente antiguos, mostrando el primer formulario, probablemente no ayuda ... ;-)
Y la primera referencia que encuentro en una búsqueda de selección sql en Google (que devuelve principalmente respuestas francesas para mí ...) primero muestra el formulario anterior (luego explica el segundo).

Solo dando algunas pistas sobre la pregunta "por qué" ... ^ _ ^ Debo leer un buen libro moderno (DB agnóstico) sobre el tema. Si alguien tiene sugerencias ...

Razones por las cuales las personas usan ANSI-89 de mi experiencia práctica con programadores y aprendices viejos y jóvenes y recién graduados:

Aprenden SQL del código existente que ven (en lugar de libros) y aprenden ANSI-89 del código
ANSI-89 porque es menos tipado
No lo piensan y usan uno u otro estilo y ni siquiera saben cuál de los dos se considera nuevo o viejo y tampoco les importa
La idea de que el código es también una comunicación para el próximo programador que acompaña el mantenimiento del código no existe. Creen que hablan con la computadora y a la computadora no le importa.
El arte de la "codificación limpia" es desconocido
El conocimiento del lenguaje de programación y SQL específicamente es tan pobre que copian y pegan lo que encuentran en otro lado
Preferencia personal

Personalmente prefiero ANSI-92 y cambio cada consulta que veo en la sintaxis ANSI-89 a veces solo para comprender mejor la declaración SQL a la mano. Pero me di cuenta de que la mayoría de las personas con las que trabajo no tienen la destreza suficiente para escribir uniones en muchas tablas. Codifican lo mejor que pueden y usan lo que memorizaron la primera vez que encontraron una declaración SQL.

Según "SQL Performance Tuning" de Peter Gulutzan y Trudy Pelzer, de las seis u ocho marcas 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 el ser humano no hace 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 las personas comiencen a usarlo! Y todas las marcas de bases de datos SQL ahora lo admiten, por lo que no hay ninguna razón para continuar usando la sintaxis aberrante (+) Oracle o la sintaxis *= Microsoft / Sybase.

En cuanto a por qué es tan difícil romper la costumbre de los desarrolladores del hábito SQL-89, solo puedo suponer que hay una gran "base de la pirámide" de programadores que codifican mediante copiar y pegar, usando ejemplos antiguos de libros, artículos de revistas, u otra base de código, y estas personas no aprenden nueva sintaxis de forma abstracta. Algunas personas combinan patrones, y algunas personas aprenden de memoria.

Poco a poco veo que las personas usan la sintaxis SQL-92 con más frecuencia de lo que solía hacerlo. He estado respondiendo preguntas de SQL en línea desde 1994.

Tenía una consulta que se escribió originalmente para SQL Server 6.5, que no admitía la sintaxis de combinación de SQL 92, es decir,

select foo.baz from foo left outer join bar on foo.a = bar.a

fue en cambio escrito como

select foo.baz from foo, bar where foo.a *= bar.a

La consulta había estado disponible por un tiempo, y los datos relevantes se habían acumulado para hacer que la consulta se ejecutara demasiado lento, y tardara 90 segundos en completarse. Cuando surgió este problema, nos habíamos actualizado a SQL Server 7.

Después de rebuscar con índices y otras provocaciones de Pascua, cambié la sintaxis de unión para que cumpliera con SQL 92. El tiempo de consulta se redujo a 3 segundos.

Hay una buena razón para cambiar.

Repostado desde here .

Un nuevo estándar SQL hereda todo del estándar anterior, también conocido como ''los grilletes de la compatibilidad''. Por lo tanto, el estilo de unión "viejo" / "separado por comas" / "no calificado" es un sintaxis SQL-92 perfectamente válido.

Ahora, sostengo que NATURAL JOIN SQL-92 es la única combinación que necesita. Por ejemplo, yo sostengo que es superior a inner join porque no genera columnas duplicadas: ¡no hay más variables de rango en las cláusulas SELECT para eliminar la ambigüedad de las columnas! Pero no puedo esperar cambiar cada corazón y mente, así que tengo que trabajar con codificadores que continuarán adoptando lo que personalmente considero estilos de unión heredada (¡e incluso pueden referirse a las variables de rango como ''alias''!). Esta es la naturaleza del trabajo en equipo y no operar en el vacío.

Una de las críticas del lenguaje SQL es que se puede obtener el mismo resultado usando una cantidad de sintaxis semánticamente equivalentes (algunas usando álgebra relacional, otras usando el cálculo relacional), donde elegir el "mejor" simplemente se reduce al estilo personal . Así que estoy tan cómodo con las uniones de ''estilo antiguo'' como con INNER . Si me tomo el tiempo de reescribirlos como NATURAL depende del contexto.