Condiciones en consultas mysql

[leif_sk8er]

Hola, me gustaria saber si es posible de alguna forma hacer lo siguiente:
Tengo una tabla de comentarios, donde aparte del comentario, la fecha y el id, tengo un campo para Id seccion y id elemento. Las id secciones son:1 para fotos, 2 para videos, 3 para lugares.

Pues bien, quiero sacar un listado de los ultimos 50 comentarios con la informacion de lo que comenta, por ejemplo:

Juan martinez dijo en el video llamado la tortilla: jejeje

Pero no me gustaria, una vez sacado las 50 filas, ir por cada uno de los resultados sacar el nombre del video, foto, o lugar.

Los videos, fotos y lugares estan en tablas diferentes, es decir en 3 tablas. Con lo que me es imposible relacionar la consulta a una de las tablas, por que hay 3 y dependiendo el id de seccion tiene que relacionar con una o con otra.

Almenos hasta donde llegan mis conocimientos basicos de sql no me es posible hacerse en una sola consulta, pero... ¿Es posible hacerse? ¿De alguna forma se pueden meter condicionales en una consulta parecidos a if/else? De no ser posible, cual seria la mejor forma que se os ocurre para hacer las menos consultas posibles.

Supongo que este es un caso muy muy tipico en cualquier tipo de proyecto, espero podais responder.
Un saludo!

[gnzsoloyo]

Los videos, fotos y lugares estan en tablas diferentes, es decir en 3 tablas. Con lo que me es imposible relacionar la consulta a una de las tablas, por que hay 3 y dependiendo el id de seccion tiene que relacionar con una o con otra.

Eso lo único que hace es obligarte a escribir una consulta algo más compleja, usando INNER JOIN, pero no mucho más que eso.
No te rindas, la cosa no es tan difícil de hacer...
La estructura básica sería:

Código MySQL:

SELECT c.*, f.*, v.*, s.*
FROM comentarios c LEFT JOIN fotos f ON c.comentario_id = f.comentario_id
LEFT JOIN videos v  ON c.comentario_id = v.comentario_id
LEF JOIN lugares s ON c.comentario_id = s.comentario_id;
 

Donde c, f, v, y s son alias de las tablas.

Este tipo de consulta devovlerá NULL en aquellas columnas donde no haya datos relacionados, y resulta funcional si un comentario puede ir acompañado de más deu na cosa, es decir si tiene relacionados además de un video, un sitio, por ejemplo, o una foto.
El resto del proceso (la representación en pantalla) la debes manejar por programación.

Otra posibilidad es usar UNION, si y sólo si cada comentario sólo puede estar acompañado de uno de esos elementos, pero no de otros. Si existe al menos un caso donde haya más de un objeto de diferente clase relacionado con el mismo comentario, el UNION ya no es funcional.

[leif_sk8er]

Mmm entonces si quiero relacionar el id_elemento de la tabla comentarios a segun que cosa tendria que seguir esto mas o menos? metiendole el id de seccion:

Código SQL:

SELECT c.*, f.*, v.*, s.*
    FROM comentarios c LEFT JOIN fotos f ON c.id_seccion = 1 AND c.comentario_id = f.comentario_id
    LEFT JOIN videos v  ON c.id_seccion= 2 AND c.comentario_id = v.comentario_id
    LEFT JOIN lugares s ON c.id_seccion = 3 AND c.comentario_id = s.comentario_id;
 

Siguiendo algo parecido a eso y valorando los null deberia poderse hacer no?

Por ultimo decir que no se realmente si esa es la mejor forma, ya que o tenia una sola tabla de comentarios, o me resultaban algunas cosas mas complicadas teniendo diferentes tablas de comentarios, una para videos, otra para fotos, otra para lugares.... Pero por otro lado no usaria left joins que creo que no suele ser bueno usarse.

Que es lo mejor?

Un saludo!

[gnzsoloyo]

Mira, por un lado aclaremos que lo que dices:

Pero por otro lado no usaria left joins que creo que no suele ser bueno usarse.

es obviamente un concepto que no has sacado de un manual.
No. LEFT JOIN no es algo que "no suele ser bueno", sino que es, en muchas ocasiones, la única solución de buena performance. Eso lo puedes ver si exploras un poco el tipo de consultas de las redes sociales.
Y es así por la razón más simple de todas: Normalmente un comentario puede tener asociados videos, fotos u otras cosas, pero precisamente eso es opcional, y no mandatorio. AL ser opcional y darse que no exista en un comentario, ningún objeto asociado, si la consulta la haces sin el LEFT JOIN todos esos comentarios simplemente no aparecerán.
¿Se entiende?

Bien, como evidentemente recién estás explorando el tema de este tipo de diseño de bases de datos, te muestro cómo es el esquema básico de una red social, donde los usuarios pueden poner diversos tipos de objetos relacionados a los comentarios (como el muro de FB):



Como puedes apreciar, efectivamente cada tipo de objeto tiene su propia tabla. No le des muchas vueltas, más allá de diferencias funcionales, eso no variará entre distintas SN.


Más o menos así opera la cosa.

[Smolky]

Lo que si que es muy importante para el rendimiento es el siguiente.

• Si tu base de datos es del tipo MyIsam tienes que indicar cuáles campos son índices para que las consultas sean realmente rápidas. Crear un índice es como indicarle a MySQL que dicho campo se suele utilizar para realizar búsquedas por lo cual, el guarda internamente un listado aparte preparado para relacionarlo con las demás tablas.
• Si tu base de datos es del tipo InnoDB entonces tienes una cosa que es integridad referencial. Puedes decir que un campo es clave ajena de otro (clave de otra tabla) por lo cual tienes automáticamente los índices comentados anteriormente más otra serie de ventajas.

Sé que estos conceptos al principio suelen ser complicados de entender, pero te recomiendo encarecidamente que los leas y comprendas por que en un sistema donde pudieras tener cientos o miles de comentarios es algo importantísimo.

Aquí tienes más información sobre las diferencias entre estos dos motores de MySQL
http://www.tufuncion.com/myisam-vs-innodb

[leif_sk8er]

Si la verdad es que mi idea es que esas tablas manejen varios millones de comentarios, o almenos plantearlo asi por que directamente aprendo a hacerlo lo mas optimo posible, no importa el tiempo que haga falta para aprenderse correctamente. Muchas gracias por el articulo, voy a leermelo ahora.

Intentaré ir poneiendo en practica este tipo de consultas a ver que tal me sale.
Un saludo!