Mejor forma de hacer esta consulta

[luismercado0209]

Hola, tengo un problema tengo dos tablas:

tabla usuarios
id
nombre
mensajes //en tas se guardan las id de los mensajes separadas por coma (,)

tabla mensajes
id
texto

mi problema es como es la mejor forma de hacer esta consulta:

tengo 1,3,5,7,9,23,57,78,98,456,567,678

necesito mostrar los mensajes todas las ids del ejemplo, ahi una forma de hacerlo sin hacer una consulta para cada id del grupo de ids, espero que me entiendan y que me ayuden.

Gracias.

[luismercado0209]

Ya lo solucion con la sentencia IN pero alguien me puede decir que tan eficiente es esta sentencia.

[gnzsoloyo]

Tienes varios problemas:
1) Estás usando un campo multivaluado (el que quieres usar en la consulta), y los campos multivaluados están totalmente prohibidos en el modelo E-R. Sólo sirven para traer problemas, como los que tienes ahora.
2) IN no te funcionará, porque opera contra listas de valores y tu tienes (aunque creas lo contrario) un único valor. El que internamente sea una lista separada por comas no importa. Es una sola cadena de texto.
3) La única "solución" que tienes es usar una función denominada FIND_IN_SET(), que puedes ver en el manual de referencia (ver el link).

Finalmente: Si quieres una solución correcta y eficiente, deberías descartar el modelado de datos que tienes y replantearlo, aplicando las reglas de diseño correctamente.
Este problema menor que tienes con la consulta será sólo el comienzo de todos los problemas futuros. Ese diseño está mal hecho
Una relación N:N como la determinada por ese campo se define creando una tabla intermedia que gestiona la relación entre el usuario y los mensajes, y no creando un campo multivaluado.

[luismercado0209]

Iniciado por gnzsoloyo

Tienes varios problemas:
1) Estás usando un campo multivaluado (el que quieres usar en la consulta), y los campos multivaluados están totalmente prohibidos en el modelo E-R. Sólo sirven para traer problemas, como los que tienes ahora.
2) IN no te funcionará, porque opera contra listas de valores y tu tienes (aunque creas lo contrario) un único valor. El que internamente sea una lista separada por comas no importa. Es una sola cadena de texto.
3) La única "solución" que tienes es usar una función denominada FIND_IN_SET(), que puedes ver en el manual de referencia (ver el link).

Finalmente: Si quieres una solución correcta y eficiente, deberías descartar el modelado de datos que tienes y replantearlo, aplicando las reglas de diseño correctamente.
Este problema menor que tienes con la consulta será sólo el comienzo de todos los problemas futuros. Ese diseño está mal hecho
Una relación N:N como la determinada por ese campo se define creando una tabla intermedia que gestiona la relación entre el usuario y los mensajes, y no creando un campo multivaluado.

Ummm pero como hago si dos o mas usuarios comparten un mismo mensaje, crearía otra relación en la tabla intermedia por cada usuario que comparta el mismo mensaje mensaje?

[gnzsoloyo]

Ummm pero como hago si dos o mas usuarios comparten un mismo mensaje, crearía otra relación en la tabla intermedia por cada usuario que comparta el mismo mensaje mensaje?

Una relación N:N (muchos a muchos), es exactamente eso: Una relación donde cada uno de los registros de la tabla A está relacionado N veces con cada uno de la tabla B. En ese caso la PK de la tabla se define con los dos campos.
Pero en el tipo de casos que te preocupa, un mismo usuario puede estar relacionado N veces no con el mensaje, sino con el thread (tema) de que se trata, como por ejemplo los de este mismo sitio.
Lo que se hace es agregar un discriminante: El numero de sub item, o numero de post del mismo mensaje, que suele ponerse con un incremental.
Así, lo único que hay que hacer es ordenar históricamente los posts relacionados con el tema.

¿Se entiende la lógica?

En el caso de mensajes que se envían a N usuarios y los que esos N usuarios le responden al remitente, la lógica aplicada es la misma: ID del remitente, ID del receptor, ID del thread si corresponde y fecha de emisión.
Todo este tipo de análisis se estudia en la universidad al cursar las asignaturas de Base de Datos. Los que no cursan, los autodidactas, se ven obligados a aprenderlo por la fuerza. Si no lo haces, los sistemas diseñados tarde o temprano terminarán colapsando por fallas de lógica y performance.

Por algo BBDD es una especialidad profesional.

En cualquier caso, te recomiendo que hagas un alto y le des una leída a los principios del mo delo Entidad-Relación (Wikipedia sirve), antes de seguir adelante.
Siempre viene bien.