Cita: no es muy habitual que sea m:n normalmente es 1:N
Tienes que tener en cuenta que cuando defines la relación ente dos entidades de la estructura de datos no lo haces sobre los casos particulares, sino sobre los generales.
SI hay
un sólo caso donde la relación ente producto y categoría sea N:N, la relación
es N:N y se crea una tabla para gestionarla,
aunque el resto de las instancias de producto sólo aparezca una vez. Lo que importa es que
debe representar el peor caso posible.
Lo que nunca puede suceder es que haya un caso en que la relación establecida ente dos tablas no permita almacenar los datos. Eso implicaría que rla relación diseñada es insuficiente,
eso no debe suceder.
Cita: pero a la hora de mostrar quiero mostrar solo a una categoría pero que se be
que pertenece a varias categorías
El problema de
mostrar algo es irrelevante para el diseño de datos. Mostrar,
es asunto de la aplicación; la base de datos sólo tiene por misión devolver la información necesaria, no perder el tiempo resolviendo cómo desea mostrarlo el programador de las aplicaciones. Sí puede aportarle retorno de datos preformateados, pero no decidir cómo aparecen en pantalla.
Precisamente por esa razón es que se enseña que una base de datos debe ser flexible y poder responder cualquier cosa que el programador requiera hoy,
o en el futuro. Y no puedes asegurar, hoy por hoy que no vas a necesitar listar
todas las categorías vinculadas a un producto... ¿no es así? Los requerimientos futuros siempre son un producto de la imaginación de los programadores... que parece ilimitada :(
En cualquier caso, si lo que deseas es mostrar un único producto y todas las categorías en que está incluido, eso es un problema de
diseño de consultas, y no de diseño de estructura de datos. La estructura tiene que poder hacerlo y para eso debe ser
flexible.