duda con consulta mysql

[Rasec101]

Buenas tardes paso a esplicar mi problema.
resulta que tengo una tablas "Articulos" que tiene esta estructura
IdArticulo | categoria | titulo | parrafo
1 | 1-2 | XXXX | XXXXX
2 | 1-3-4 | XXXX | XXXXX
3 | 2-4 |XXXX | XXXXX

la idea es hacer una consulta que me arroje el siguiente resultado:
IdArticulo | categoria | titulo | parrafo
1 | 1 | XXXX | XXXXX
1 | 2 | XXXX | XXXXX
2 | 1 | XXXX | XXXXX
2 | 3 | XXXX | XXXXX
2 | 4 | XXXX | XXXXX
3 | 2 | XXXX | XXXXX
3 | 4 | XXXX | XXXXX

lo necesito para listar articulos por categorias y el campo categorias es varchar(20) ojala alguien me pueda dar una mano.

[gnzsoloyo]

La tabla "Articulos" está mal diseñada. Los campos multivaluados como el que has puesto (categorías) están completa y absolutamente prohibidos en las base de datos.
Corresponde que exista una relación N:N entre la tabla Artículos y la de Categoría, es decir, te falta una tabla que relacione cada artículo con las categorías (un registro por cada categoría con que se relacione).
Sin eso, no es posible realizar la consulta en SQL.

Empieza por corregir el error.

[Rasec101]

Gracias gnzsoloyo por responder. aver la solucion en crear una tabla categoria con los campos idCategoria | nombre y dejar la tabla Articulo con la siguiente estructura IdArticulo | idCategoria | titulo | parrafo. y almacenar los articulos por separado segun la categoria es desir repetir el registro en articulos pero con diferente categoria???

[gnzsoloyo]

Así es como se hace.

Cuando tienes una relación N:N entre dos entidades, la relación debe convertirse en el modelo físico en una tabla cuya PK está comuesta por las PK de las otras dos tablas. De ese modo no existirá duplicacion del par de valores.
Esta tabla relacional puede llevar otros atributos si y sólo si son necesarios.

Hay algunso detalles más (que se suelven estudiar bien cuando cursas la carrera), pero en general esa es la idea.

Luego, cuando haces las consultas, relacionas las tres tablas en un INNER JOIN y listo.

Este tipo de esquemas lo encontrarás siempre que haya una relación de muchos a muchos.

[Rasec101]

Iniciado por gnzsoloyo

Así es como se hace.

Cuando tienes una relación N:N entre dos entidades, la relación debe convertirse en el modelo físico en una tabla cuya PK está comuesta por las PK de las otras dos tablas. De ese modo no existirá duplicacion del par de valores.
Esta tabla relacional puede llevar otros atributos si y sólo si son necesarios.

Hay algunso detalles más (que se suelven estudiar bien cuando cursas la carrera), pero en general esa es la idea.

Luego, cuando haces las consultas, relacionas las tres tablas en un INNER JOIN y listo.

Este tipo de esquemas lo encontrarás siempre que haya una relación de muchos a muchos.

Gracias gnzsoloyo si la verdad lo que no queria era duplicar demaciados registros en la base de datos ya que un articulo puede estar relacionado a 20 categorias distintas lo que implica duplicar el registro por las 20 categotegorias

[gnzsoloyo]

No lo estás viendo correctamente: No existe duplicidad si el par no se repite.
Y lo que pierdes en atomizar la relación lo ganas en las consultas y en la integridad referencial, que en tu caso se ha perdido completamente.
En tu modelo, puedes tener repeticiones de categorías hasta el infinito, y no podrías detectarlo.

[leonardo_josue]

Iniciado por Rasec101

Gracias gnzsoloyo si la verdad lo que no queria era duplicar demaciados registros en la base de datos ya que un articulo puede estar relacionado a 20 categorias distintas lo que implica duplicar el registro por las 20 categotegorias

Hola Rasec101:

Independientemente de que un articulo pueda tener 1, 20 o 200 entradas en una tabla, siempre será mejor manejar el modelo que atinadamente te propone gnzsoloyo contra lo que intentas hacer... razones son muchas, pero aquí hay algunas:

1. Uso de índices: en un campo multivaluado no puedes definir índices, por lo tanto no puedes tener una integridad referencial completa, las consultas serían mucho más lentas y las consultas más complejas.

2. Ahorro de espacio. tal vez pienses que es mejor tener 1 registro que 20, pero el desperdicio de memoria es enorme. Para comenzar, con el modelo que planteas deberás asegurarte que la longitud del campo sea lo suficientemente grande como para soportar todos los posible valores, lo más usual sería declarar de tipo varchar con una longitud enorme, pero veamos este caso:

IdArticulo | categoria | titulo | parrafo
1 | 1 | XXXX | XXXXX
2 | 1-2 | XXXX | XXXXX
3 | 1-2-3-4-5-6-7-8-10-11-12-13-14-15-16-17-18-19-20 |XXXX | XXXXX

para este caso tu campo "CATEGORIA" debería tener al menos una longitud de 48 caracteres, para poder soportar la cadena del registro 3, sin embargo, HAY UN DESPERDICIO de 47 caracteres en el registro 1 y de 45 caracteres en el registro 2.
multiplica esto por cada registro. Con el otro modelo NO EXISTE DESPERDICIO DE MEMORIA, y tus relaciones PODRÍAN CRECER SIN LÍMITE, es decir, da lo mismo que tengas 1 relación, 20 o infinito.

3. Manejo de operaciones de (Altas, Bajas, Cambios). Estas operaciones se manejarían de forma "natural", es decir, para altas utilizas INSERT, para bajas DELETE y para modificaciones UPDATE. Con tu modelo por ejemplo una alta podrías manejarla con un INSERT si es que no existe un registro para esa categoría o un UPDATE, deberás verificar que la categoría exista y concatenar el registro que quieres agregar al campo. Lo mismo sucede para las eliminaciones, podrías hacerla con un DELETE la referencia está sola o con un UPDATE (recortando sólo la parte que quieres eliminar).

Podría seguir ennumerando casos, pero creo que es más que evidente por qué no es conveniente que manejes el modelo que propines al principio,

Saludos
Leo.

[Rasec101]

Gracias a ambos voy a restructurar las tablas la verdad estaba bastante complicado con el asunto y con su ayuda ya tengo la idea por donde devo empesar muchas gracias