La verdadera pregunta es: ¿Estos registros tienen una relación uno a uno o una relación uno a muchos ?
Respuesta TLDR:
Si es uno a uno, use una JOINdeclaración.
Si es uno a muchos, use una (o muchas) SELECTdeclaraciones con optimización de código del lado del servidor.
Por qué y cómo usar SELECT para la optimización
SELECT'ing (con múltiples consultas en lugar de uniones) en un gran grupo de registros basado en una relación uno a muchos produce una eficiencia óptima, ya que JOIN' ing tiene un problema de pérdida de memoria exponencial. Tome todos los datos, luego use un lenguaje de script del lado del servidor para resolverlos:
SELECT * FROM Address WHERE Personid IN(1,2,3);
Resultados:
Address.id : 1 // First person and their address
Address.Personid : 1
Address.City : "Boston"
Address.id : 2 // First person's second address
Address.Personid : 1
Address.City : "New York"
Address.id : 3 // Second person's address
Address.Personid : 2
Address.City : "Barcelona"
Aquí, obtengo todos los registros, en una declaración de selección. Es mejor que JOINobtener un pequeño grupo de estos registros, uno a la vez, como un subcomponente de otra consulta. Luego lo analizo con un código del lado del servidor que se parece a ...
<?php
foreach($addresses as $address) {
$persons[$address['Personid']]->Address[] = $address;
}
?>
Cuándo no usar JOIN para la optimización
JOIN'formar un gran grupo de registros basado en una relación uno a uno con un solo registro produce una eficiencia óptima en comparación con múltiples SELECTdeclaraciones, una tras otra, que simplemente obtienen el siguiente tipo de registro.
Pero JOINes ineficiente cuando se obtienen registros con una relación de uno a muchos.
Ejemplo: la base de datos Blogs tiene 3 tablas de interés, Blogpost, Tag y Comment.
SELECT * from BlogPost
LEFT JOIN Tag ON Tag.BlogPostid = BlogPost.id
LEFT JOIN Comment ON Comment.BlogPostid = BlogPost.id;
Si hay 1 blogpost, 2 etiquetas y 2 comentarios, obtendrá resultados como:
Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag2, comment1,
Row4: tag2, comment2,
Observe cómo se duplica cada registro. Bien, entonces, 2 comentarios y 2 etiquetas son 4 filas. ¿Qué pasa si tenemos 4 comentarios y 4 etiquetas? No obtienes 8 filas, obtienes 16 filas:
Row1: tag1, comment1,
Row2: tag1, comment2,
Row3: tag1, comment3,
Row4: tag1, comment4,
Row5: tag2, comment1,
Row6: tag2, comment2,
Row7: tag2, comment3,
Row8: tag2, comment4,
Row9: tag3, comment1,
Row10: tag3, comment2,
Row11: tag3, comment3,
Row12: tag3, comment4,
Row13: tag4, comment1,
Row14: tag4, comment2,
Row15: tag4, comment3,
Row16: tag4, comment4,
Agregue más tablas, más registros, etc., y el problema se inflará rápidamente a cientos de filas que están llenas de datos en su mayoría redundantes.
¿Cuánto te cuestan estos duplicados? Memoria (en el servidor SQL y el código que intenta eliminar los duplicados) y recursos de red (entre el servidor SQL y su servidor de código).
Fuente: https://dev.mysql.com/doc/refman/8.0/en/nested-join-optimization.html ; https://dev.mysql.com/doc/workbench/en/wb-relationship-tools.html
