Cita:
Iniciado por gnzsoloyo 
En una relación N:N no existe repetición de datos. Lo único que se relacionan son las PK de ambas tuplas, porque además una relación N:N crea una nueva tabla donde la PK está compuesta de la sPK relacionadas.
Una relación N:N, podría servir para tu caso perfectamente porque al almacenar la clave de registro de "POLLO" con la de "PAVO" y los demas productos similares, si haces una consulta puedes obtener toda la lista de "parecidos".
No te olvides: Sólo se trata de una tabla relacional. No hay duplicación de datos.
Tienes razón para el tema de alimentos "parecidos" ya que hay que meter lo datos de todos los alimentos sí o sí, pero el problema sería en el tema de "iguales". Pongo un ejemplo, a ver si me hago entender. Para poder relacionar "ANCHOA" y "BOQUERÓN" tengo que tener ambos registros rellenados. Imaginemos que la tabla alimentos contiene 20 campos (ID, NOMBRE, TIPO ALIMENTO, VALOR NUTRICIONAL, PRECIO MEDIO,... hasta 20 campos). Veo dos opciones para trabajar con esto:
- Rellenar los 20 campos de los dos registros con los mismos datos (ya que son lo mismo). Por esto decía que tendría datos repetidos. Además, para todos los sinónimos puede traer un trabajo considerable.
- Dejar un registro rellenado completamente (siendo el registro principal, por decirlo de alguna manera), y los sinónimos solo con los datos obligatorios (ID y NOMBRE por ejemplo). En este caso, ¿estaría bien tener registros con varios campos vacíos? ¿Que sistema se suele usar en estos casos para intentar guardar la base de datos consistente? Quiero decir, para tener un sinónimo, tiene que haber primero un registro principal, ¿cómo controlo esto?
¿Veis alguna otra opción?