Explicación visual de los Joins de SQL

Una forma rápida de entender los distintos Joins que hay en SQL

[#1 Florida_man]

Ni de coña saldrá a portada y es bastante vieja... pero espero que a alguien le sea útil

[#3 Desactivado]

#1 Pues a los DBAs de palo como yo nos viene de puta madre.

[#4 Florida_man]

#3 es que si tienes que entenderlo leyendo la wikipedia: http://es.wikipedia.org/wiki/Join o el manual http://dev.mysql.com/doc/refman/5.0/es/join.html te puedes volver loco.

[#18 Balobaloba]

#1 Que sea vieja no tendría que ser motivo para que no saliera a portada si sigue estando vigente y es útil... que lo está y lo es, vaya, que no han cambiado el funcionamiento de las joins recientemente
Así que meneo

[#19 Usul._.]

#18 Iba a decir que aparte de vieja es una explicacion bastante tipica y ya sabida, pero claro, por que en algun momento se estudio/vio. Creo que me va a servir para ver si en mi curro aprender a hacer las querys como es debido..

[#22 Desactivado]

#1 Oye, muy bien explicado y muy simple de entender de verdad. Si tienes más cosillas del estilo compártelas por favor.

Un saludo y gracias por el aporte.

[#27 Ferran]

#1 FAIL llegó a portada

[#5 alexwing]

Voy a fumarme un join después de esto.

[#9 Xtampa2]

Meneo por la sorpresa que me he llevado al ver algo explicado tan sencillamente. Yo también pertenezco al club de los no tan listos.

[#25 llamamepanete]

El artículo es muy bueno.

Faltaría la explicación visual de un SQL Injection:

http://apuntesnihongo.files.wordpress.com/2010/06/bandera-imperial-de-japon.png

[#28 KimDeal]

#25 qué bueno!

[#44 KimDeal]

#36 yo no digo que no se pueda esquivar un join, lo que me sorprende es que alguien pueda tener el título de ingeniero informático sin tener claro como funciona una join.

Por otra parte, suele ser más óptimo a nivel de consumo de recursos utilizar joins que sql anidado. Y a nivel de programación es más sencillo utilizar joins.

[#48 Desactivado]

#44 Seguro que es más óptimo utilizar Joins que sql anidado? Permíteme que lo duda. Será en tablas ridículamente pequeñas, pero en tablas gigantes precisamente se desaconseja utilizar Joins, son como la peste para los dba. Por supuesto, el anidamiento solo tiene sentido si se trabaja siempre con índices.

Un saludo.

[#50 KimDeal]

#48 si la join está bien hecha, funciona perfectamente. Yo utilizo joins en tablas de más de 5 millones de registros.

Los dba se ponen nerviosos con mucha facilidad, porque hay gente que no sabe utilizar joins, pero tampoco saben utilizar sql anidado. Lo que no puede ser es ponerse irracional porque un dba tuvo un par de malas experiencias con joins. Sólo que saber darles garantías sobre la sentencia sql que hemos programado.

[#47 Desactivado]

#36 Los JOINs permiten optimizar consultas aprovechando el conocimiento que tiene la BBDD de los índices de los datos que contiene. A partir de determinado nivel de complejidad, cantidad de datos y variabilidad de las consultas, puede suponer órdenes de magnitud de diferencia en el rendimiento.

[#29 jsianes]

Cada vez que un programador usa una sentencia JOIN sin pensar el gatito de un administrador de sistemas muere

[#46 Desactivado]

Esto ya tiene mucho tiempo.

Sin embargo voy a poner un enlace en Español que se basa en lo mismo (de hecho lo saca de ese mismo enlace): http://boozox.net/mysql/explicacion-visual-de-los-sql-join-unir-tablas-con-sql/

[#2 Desactivado]

Meneo...

[#75 Desactivado]

#36 Madre mía... O sea, que para ti cruzar consultas en PHP "apenas penaliza la CPU" respecto a hacer un JOIN. Y ni siquiera distingues entre cargar el servidor "web" y cargar el servidor de datos. Sinceramente, espero no encontrarme NUNCA con una de tus "miles de líneas de código".

El mundo está lleno de pseudoinformáticos que programan sin saber qué hacen.

#74 Con todos los respetos, si usas entre 5 y 20 tablas no es una "aplicación web", es una "webecilla". Y la calidad del código no se mide según los caracteres que ocupa, por dios.

En sólo dos comentarios me has hecho temer por el presente y futuro de Internet. Te lo juro.

Así cuesta luego cobrar decentemente aplicaciones de calidad, no te jode...

[#76 Desactivado]

#75 Pones en mi boca afirmaciones que no he dicho y sobre ellas me descalificas. Así que ale, sirvete

[#77 Desactivado]

#76 Chiquillo, que te he citado literalmente. ¿O ni siquiera sabes lo que has escrito? (que no me extrañaría, visto lo visto)

[#78 Desactivado]

#77 Te cito literalmente: "si usas entre 5 y 20 tablas no es una "aplicación web", es una "webecilla""

Wordpress tiene entre unas 9 tablas. Y no solo no es una webecilla, si no que tiene tanta o más complejidad que la gran mayoría de webs.

Creo que el problema de tu picada y demagogia es simple. Tu debes ser el arquitecto de Facebook o de un banco. Y siendo así te doy la razón de que en aplicaciones de ese calado no usar JOINS en lugar de SQL anidados es una locura y 15 tablas es moco de pavo.

Sin embargo yo me estaba refiriendo en todo momento a aplicaciones general, es decir de "la amplia mayoria de aplicaciones web". Y no precísamente de Google, ni Facebook. Si no de webs de complejidad normal. Si quieres entrar en la conversación y hacer una opinión desde tu punto de vista hazlo, especifica a qué te refieres, pero sin echar abajo la opinión de los demás (ten en cuenta que a parte de leer libros como tu he probado empiricamente que las consultas anidadas de SQL no consumen tanto y para una web normal se puede usar perfectamente, para eso existen).

Pero para qué me molesto en explitarte, si me vas a contestar con algun ataque personal tipo "chiquillo" o "pseudoinformatico". ¿Verdad?

[#79 Desactivado]

#78 No es ningún ataque personal, hijo, es que es como ver a un panadero aleccionando a los demás sobre arquitectura. Y los profesionales llevamos muchos años sufriendo la desconfianza empresarial hacia el gremio cultivada y regada por mendrugos como tú, que ni saben lo que hacen.

Ciertamente Wordpress no es una "webecilla". No llega ni a eso. ¡Sólo es un "blogger"! Está claro que cualquier cosa cuyo resultado sea una página "web", PARA TI es una aplicación compleja.

Así es lógico que llames "aplicación" a cualquier cosa, claro. ¿Qué demonios entiendes tú por "aplicación"? ¿Un formulario, un paginador de datos, la maquetación de un texto guardado en una tabla...? ¿Consideras que un tocho es un edificio? ¿Un triciclo es un vehículo comparable con un avión?

Tu problema es que llamas "webs de complejidad normal" a cosas que no tienen complejidad alguna, sencillamente porque en tu vida has hecho una aplicación empresarial ni una "web" mínimamente compleja. Y como tú sólo sabes hacer la O con un canuto, asumes que eso es la "complejidad normal". Tu error quizá sea comprensible, pero no deja de ser un error.

Y no te piques, hijo, que eres tú solito quien se ha dejado el culo al aire. Basta con remitirse a tu primer comentario (#36) para certificar que no tienes ni idea. Pero ni puñetera idea, ¿eh? Sólo leyendo eso, ni remotamente te encargaría yo una sola línea de código, chico.

[#43 mcklaw]

#36 O como en Google App Engine, que directamente no se puede...

[#56 Desactivado]

No hacen falta los joins, excepto en muy contadas ocasiones. Se consigue lo mismo por otras vías. De todas formas, está bien explicado.

[#45 joffer]

#36 pues si realmente usas BD de vez en cuando, te aconsejo muy mucho el uso de joins. Las consultas anidadas pueden suplirlos aveces otras no y para lo básico usar joins es bien sencillo y rápido. Así que ya te estás poniendo las pilas

[#55 Observer]

#8 Tu problema no son los join, fueron los profesores seguramente.
Yo los entendí muy bien. Claro que además, encuentro el sql extremadamente divertido. ^^

#11 Hombre, sirve para explicarlo de una forma visual a quien no lo entiende. Mal explicado como bien indicas pero sirve.

#45 Apoyarte en el php/jsp/etc para filtrar datos es un error, obligas a la bd a enviar datos innecesarios.

#49 En realidad lo que cuestionan es que sea util realmente, ya que como indica #11 no esta bien explicado.

[#57 Pumba]

#31 Lo dudo, a lo mejor alguno hay, pero no es mi caso, ya tiraba joins antes de hacer la asignatura... ¿lo dices por mi?

#55 Es posible, yo tampoco tuve problemas con ellos, pero compañeros que no los entendían sí que tenía, pero ya sabes que "cada maestrillo tiene su librillo". A lo mejor en mi caso se centraban en explicar tanta tanta y tanta teoría que se olvidaban de lo más básico: entender.

#51 Osti tú, ¿por una asignatura ya condenas a toda una facultad? Apuesto que incluso en tu facultad había profesores malos. En mi caso mi profesora yo creo que era buena, y sabía de sgbd lo que no está escrito, otra cosa es que diera las clases cagando leches.

#36 Yo creo que son necesarias, en mi día a día con bases de datos de tamaño considerable (100 o 200 tablas) para ciertos casos es necesario obtener información disgregada. En términos de rendimiento no es lo mismo 15 consultas y en memoria "construír" el resultado que necesitas, que hacerlo con un sólo JOIN.

[#63 Zade]

#57 Muy rápido puede ir tu profesora, pero si lo segundo que dice después de "buenos días"el primer día de clase, no es que las bases de datos relacionales se basan en el álgebra relacional y que eso es la que las diferencia de otros tipos de bases de datos... es que algo falla....

Y si ni siquiera aparece en los apuntes, ya lo que falla es la facultad... ¿se puede condenar a toda una facultad por un fallo? En este caso tan flagrante sí.

Otra cosa es que fuese tan rápido que lo dijera y tu no te dieses cuenta, de todas formas, esto no es un dato anecdótico que se dice de pasada. No es por ser desconfiado y no te lo tomes a mal, pero dudo mucho (muchísimo) que tu profesora no os explicara esto. A ver si ese día estabas malo....

Si Codd levantara la cabeza....

PD: No os ensañéis con #6. Si, ha sonado muy prepotente, pero es que no le falta razón. En ningún momento dice en su comentario que no venga bien a quien esté aprendiendo, se refiere claramente a los que trabajan a diario con bbdd, y en esto, no le falta razón. Ya me imagino yo a un cirujano operando y mirando dibujitos para entender algo que debería saberse como las vocales....

[#65 Pumba]

#63 Pero espera, espera, ¿en qué momento he dicho yo que no haya dicho eso mi ex-profesora? Porque aquí estáis dando por hecho unos cuantos que ha sido así.

Sólo he dicho que se entiende mejor gráficamente que leyéndose la teoría del álgebra relacional o analizando los resultados para cada tipo de JOIN, cosa que ha indignado notablemente a los más listos de la clase.

[#72 Zade]

#65 Discúlpame si leí mal entre lineas, he visto que alguien te ha dicho que no es buena facultad si no te han explicado que las bases de datos relacionales se basan en el álgebra relacional, y como te has excusado en la rapidez de tu profesora y no has desmentido que no se te haya enseñado así, pues ya di por hecho que tu no lo diste así. De todas formas, perdón por malinterpretarte.

Se entiende muy bien gráficamente sí, pero yo esos gráficos ya los dí en álgebra relacional para entender el álgebra relacional (que no sólo está presente en esa asignatura, si no en una buena parte de asignaturas de la carrera). Teniendo esto en mente, saber utilizar una base de datos relacional, ya solo es cuestión de práctica.

Y no es por listo de la clase ni nada, a los que estén aprendiendo les viene genial, pero para alguien que es ingeniero informático no saber esto es como si no supiese multiplicar. Llámalo arrogancia o como quieras, pero si que hay "ingenieros" así en este país y así nos luce el pelo. Hay algunos con título que ven un asterisco delante de una variable en C y no saben qué puñetas es....

[#73 Pumba]

#72 O a lo mejor yo no me expresé bien, es posible. La profe que yo tenía (Nieves) para mí era un cocazo, pero daba las clases a toda leche

En todo momento me he querido referir a la utilidad de esta página cuando estás estudiando, ahora pues a los que ya vivimos de esto poco nos puede aportar, pero es una buena forma de explicarlo, es todo lo que yo he querido hacer notar.

Y en lo que sí estoy de acuerdo es que todo ingeniero informático es obvio que estas cosas las tiene que conocer, pero me quise referir en todo momento (como indiqué en mi primer comentario) a la etapa de estudiante.

[#17 equisdx]

#16 Mea culpa, estaba confundiéndola con el álgebra relacional... http://es.wikipedia.org/wiki/%C3%81lgebra_relacional

[#39 Invid]

Blade Runner mode....On
"he visto querys ardiendo mas alla de Orion"

[#69 Observer]

#68 Por eficiencia vas a crear indices en los campos que sea necesario.
Si ordenas, filtras o realizas un join por un campo lo lógico es usar indices.
Esto puedes no hacerlo si la tabla no va a pasar de unas pocas tuplas ya que la diferencia entre recorrer menos de 100 tuplas y usar el indice puede ser ninguna o incluso a favor de no usar el indice.

[#49 Guiden]

Joder mucho Mr. Arroganto veo por aqui,
aqui nadie cuestiona si un informático sabe o no sabe como funciona una join de los cojones sino la nueva manera ilustrativa y mas eficaz de entenderlo. Personalmente me parece de puta madre este metodo puesto que soy estudiante y da la casualidad que lo esto dando y seguramente no sere el único pero bueno parece que os pese que salga a portada por que algunos de vosotros ya lo sabeis de sobra y quereis dejar constancia.

[#15 Desactivado]

Me recuerda mis viejos tiempos con Oracle 5 para OS/2 muahahah eso era sufrir y no lo de ahora que viene todo hecho y encima se quejan [modo cebolleta off;]

[#23 fidelo]

A mi me lo explicaron de una forma bastante parecida (GS Sistemas en Red), tanto en operaciones de conjuntos como con álgebra relacional. Es algo abstracto hasta que empiezas a hacer consultas. También está muy relacionado con las leyes De Morgan (aquello que se estudiaba en filosofía de bachillerato que todo el mundo se quedaba con la cara a cuadros por que no servía para nada ).

[#34 Desactivado]

Mi gran amigo el SQL, ¡cuántas noches juntos de borrachera sin dormir! Meneo

[#37 estoyausente]

jiji aun recuerdo mi pedazo 8 en Base da datos jejjej

[#20 jfabaf]

Pues yo la veo interesante, así que meneo.

[#30 Desactivado]

Ojalá lo hubiese tenido cuando programaba los ficheros lógicos (LF) (vistas) en el AS/400.

[#21 Desactivado]

Los JOINS son bastante faciles, pero esta bien que quede explicao

[#24 Nandove]

Muy pero que muy bien explicado! Yo ya sabia la diferencia entre los join(aquí es donde todo el mundo me dirá "si claro, claro... " :p) pero me viene de perlas para explicárselo a un cenutrio que por mas que se lo explicaba no lo entendía, si aun así no lo entiende, me rindo!

Por cierto hay meneo!

[#26 Desactivado]

Llevaba varios días sin cagar, pero saber cómo funciona un Join acaba de liberarme. Gracias.

[#32 tranki]

Ya se sabe: vale más una imagen que cien palabras

[#33 Invid]

Jajjajaja, piensen en esos pequeños gatitos, que los SQLServer asesinan...

[#35 Invid]

declare@MasacraGatos;
set@MasacraGatos = 'select a.*,b.* from tabla a, tabla b where a.cod=b.cod'
exec (@MasacraGatos);
--Muahahahaha

[#52 Desactivado]

Muy pero que muy útil para los novatos en SQL

[#61 Desactivado]

DBAs que nunca han usado joins o que cuando lo hacen utilizan campos que no son ni primary keys ni foreign keys como en el artículo?? Que miedo!!

[#66 Observer]

#61 Tu no has mirado la direccion web ¿verdad? www.codinghorror.com

#62 Evita table scan para busqueda de datos no indexados, bloqueos de registros, interbloqueos entre transacciones...
Espero que sea por algo tipo "like '%loquebusco%'" o es culpa del dba hacer búsquedas sin usar indices.

#64 Sencilla pero errónea. Las relaciones no tienen porqué ser 1-1, pueden ser 1-n.

[#68 Invid]

#66 cuando la Join la haces por un campo no indexado ya estas haciendo un table scan. por que la tabla, al no estar indexada por ese campo, se tiene que recorrer toda la tabla.

Y tampoco vas a crear indices en todos los campos

[#70 Desactivado]

#66 Si, y el dando un ejemplo de join sin utilizar primary key le cualifica para ser un coding horror. Eso si, lo graficos son muy bonitos. Ejecuta regular select queries y mira el execution plan para que veas lo que realmente ocurre cuando.

Cuando el uso de joins se hacer mas prohibitivo es cuando en una query empieza ha hacer join a traves de muchas tablas si tienes muchos muchos records or cuando eres Facebook, Twitter o uno de esos y tienes que mirar a alternativas tipo Casandra.

En general si una aplication va lenta y ves joins en la web es porque los foreign keys no han sido indexados, ya que estos no se crean automaticamente como el index de una primary key, y si el DBA anda mirando webs como la del articulo es que es muy muy pero que muy junior.

[#62 Invid]

A ver.... Vale que las joins son utiles para cruzar, filtrar datos...
Pero el lenguaje SQL es un estandar (muuuy reducido dicho estandar), el SQLServer, Oracle, DB2 tienen sus propias funciones, comandos y parametros. Ok si es para aprender joins pero el resto de las funciones son tambien de utiles.
no es lo mismo un To_char() en Oracle que un Cast en DB2 o un Convert en SQLServer, por no decir los comandos de estadisticas de tablas, creacion de tipos de indices, particionamiento de tablas, foreing keys..

Y por otro lado, Sabeis lo que es una ETL? un Servicio de integracion? Quita trabajo al servidor de BBDD en todo el trabajo de transformaciones, y tambien... las joins.
Evita table scan para busqueda de datos no indexados, bloqueos de registros, interbloqueos entre transacciones...

Las join son utiles, pero no son la ostia.

el comando Merge soluciona mucho, en cuando a rendimiento y transacciones.

[#6 Desactivado]

Si alguien quiere dedicarse, o se dedica, a esto de las bases de datos y necesita unos dibujos para entender algo tan simple como unos join...mejor que se dedique a otra cosa.

[#7 Desactivado]

#6 Si alguien quiere dedicarse [..] a esto de las bases de datos y necesita unos dibujos para entender algo tan simple como unos join ... mejor que se dedique a otra cosa.

Cerrad bien las ventanas y esconded a vuestras hijas... ha llegado el Juez Dredd.

[#53 Desactivado]

#7 Una bonita cheatsheet en A4

[#54 Desactivado]

Perdón, la misma que #53 pero en 300ppp (mejor calidad)

[#8 Pumba]

#6 Seguramente si en la facultad me lo hubiesen explicado así los hubiese entendido mejor. No todo el mundo nace sabiendo, es un defecto que tenemos algunos

[#11 Desactivado]

#6 Sonará a prepotente mi comentario pero es que es verdad, es algo bastante sencillo
#8 Pues muy malo debió ser tu profesor

Además ¿realmente aportan y explican algo esos diagramas? ¿Me estáis diciendo que sin el texto explicativo de la izquierda y de los ejemplos se entendería algo con los diagramas (a parte de que se necesitaría primero conocer conceptos como claves primarias y foráneas)? ¿En qué se basa uno para saber como se hace la diferencia o la intersección viendo los diagramas? Y encima, en un join, salvo que se indique lo contrario, puede haber resultados repetidos, cosa que en las operaciones entre conjuntos no.

[#12 Pumba]

#11 Pues sí, suena un poco prepotente, para qué negarlo.

He aquí el temario de BD1 de mi carrera / facultad: https://campusvirtual.udc.es/guiadocente/guia_docent/index.php?centre=614&ensenyament=614111&assignatura=614111201&pas=3

Ahora bien, tú ponte en el pellejo e un profesor que tiene que impartir en 4 meses bastante materia (y aquí en el exámen entraba absolutamente todo), y también ponte en el pellejo del alumno que no ha visto bases de datos en su vida (no era mi caso, pero había unos cuantos).

Entender estas cosas se entienden a base de práctica, y, está claro que gráficamente se entiende mucho antes que analizando los resultados, tan sólo eso.

¿Qué a ti te parece una chorrada? Otros le sacaremos utilidad. Aunque tú debes ser de los que en la carrera todo le pareció fácil (cuando habían aprobado claro)

[#16 Desactivado]

#12 No has escrito ningún argumento contradiciendo lo que he dicho sobre que estos diagramas no valen para entender nada sin las explicaciones ni ejemplos de la izquierda; es más sigo diciendo que no aportan nada

#13 En la mía tampoco; además como ya he dicho el álgebra de conjuntos no es correcta para explicar los joins debido a las repeticiones

[#31 KimDeal]

#8, #12 ¿Me estáis diciendo que uno se puede sacar el título de informático sin tener claro que es una join, un inner join, un left outer join, un right outer join, etc?

[#36 Desactivado]

#31 Si, he escrito decenas de miles de lineas de codigo (gran parte de ello es publico) y jamás he usado una JOIN. Se puede esquivar casi siempre apoyandote en PHP y que es rapidísimo y con consultas anidadas en SQL sin apenas penalización de CPU.

Realmente si no lo sé usar a estas alturas es por una sencilla razón, nunca lo he necesitado.

Ahora bien, este articulo me viene de perlas, porque ya me toca ponerme las pilas con el JOIN.

[#71 Desactivado]

#36 Si nunca has usado un JOIN no me extraña que hayas escrito decenas de miles de lineas de código, tal vez millones...

[#74 Desactivado]

#71 jaja muy gracioso.

La verdad es que fuera de la exageración tienes razon. Hoy he convertido una consulta a INNER JOIN y el resultado es más rapidez y menos caracteres de codigo. Pero vamos, unos pocos caracteres más en comparación con una consulta con SQL anidado.

Aunque he de aclarar que programo aplicaciones web, que a nivel de base de datos son cosas muy sencillas. Entre 5 y 20 tablas.

[#38 orasio]

#12
No sería una chorrada, si por lo menos explicada claramente cómo funciona todo esto.
El artículo está demasiado simplificado, y parece escrito por alguien que no tiene 100% claro el asunto, o que al menos no tiene interés en explicarlo.

La mejor forma de comprender los joins es a través del álgebra. Yo también tuve un curso de 4 meses, y me parece más que suficiente para comprender los fundamentos. Los detalles técnicos del DBMS que uses son mucho más fáciles de aprender, con un buen fundamento.

Cualquier explicación más o menos razonable comenzaría con el producto de tablas como caso generasl (cómo se representa como diagrama de conjuntos?), refinando hacia los casos más particulares como el inner join, aunque sea de los más comunes.

[#13 equisdx]

#8 coincido con #11, en la facultad te lo explican mediante Álgebra de conjuntos para entenderlo de forma más abstracta.

[#14 Pumba]

#13 No, en tu facultad en todo caso

[#51 howl]

#14 Mal vamos si hay facultades que explican bases de datos relacionales sino es a partir de su base y fundamento principal, el álgebra relacional. Aunque sea di a cual vas para incluirla en la lista de facultades que ofertan homeopatía, ya que estaría al mismo nivel.

[#60 visualito]

#11

¿aporta algo la teoría de conjuntos a las bases de datos?

El que responda que no, que se dedique a otra cosa.

[#64 Desactivado]

#11 Es una explicación gráfica sencilla de algo que no es tan sencillo como pretendes hacer creer. ¿Tanto te jode?

Y te digo una cosa: dime de lo que presumes y te diré de lo que careces. Me da la sensación de que necesitas demostrar que eres muy bueno para llenar otras carencias.

[#67 Desactivado]

#6 Que me pongan negativos me da igual; lo triste es ver que simplemente hace eso y no te rebaten lo dicho en el mensaje #11

#64 ¿Presumir de saber hacer un join? Es que como si un matématico presume de saber sumar con decimales.

[#10 Desactivado]

#6 Si un profesor necesita explicarle a alguien que se inicia en bd los joins con ejemplos sencillos y de una forma clara, sino utiliza esta forma es que no se merece dedicarse a la enseñanza.

[#40 Desactivado]

#6 Hola arrogancia, ¿qué tal estás?

[#41 AaLiYaH]

#6 hay gente que estará cursando bases de datos en estos momentos y le vendrá bien, no crees? Claro, que a lo mejor para ti gente incapaz de entender un join nada más verlo merece la muerte. Yo entendí los JOIN a la primera cuando di Bases de Datos, pero hay que ser un poquito tolerante sabes?

No se muy bien como es el temario del FP (estudié la ingeniería), pero dudo mucho que sepan algebra relacional (que aunque no es comparable si que es fundamental para luego entender cualquier consulta), así que un explicación gráfica les puede ser de muchísima utilidad.

Baja un poco de tu pedestal campeón, que la gente no nace sabiendo.

[#42 Invid]

a #6 le mataron el gato en su primer dia con el SQL

[#58 Desactivado]

#6 Mejor dedicarse a trolear un post de meneame. Estoy deacuerdo contigo.

[#59 Pumba]

#6 Por cierto, me has recordado a cierto JP al cual le enseñé unos diagramas de casos de uso y me preguntó que "qué eran esos macacos mal pintados"

Para ciertas cosas aún utilizamos boli y papel