Actualmente tengo una base de datos con dos tablas llamadas Artículos y etiquetas. Para permitir que los artículos estén en múltiples categorías, tengo una relación de muchos a muchos. ¿Es un error tener un diseño así en términos de rendimiento? ¿o debería eliminar la relación entre estas dos tablas y agregar una tercera tabla como puente (articlesTags)?relación muchos a muchos en el diseño de la base de datos
No hay nada intrínsecamente incorrecto en tener una relación muchos a muchos, solo tendrá que crear un Junction Table (que es lo que parece que se refiere al articlesTags) para facilitar esa relación.
No hay problema con tener una relación muchos a muchos si eso es lo que requieren los datos, pero querrá una tercera tabla para representarlo.
Yo diría "necesitarás una tercera mesa". – Dave
Existe una relación de muchos a muchos en un modelo de relación, es solo una abstracción de la mente. Cuando se implementará que habrá una mesa articles_to_tags donde tendrá:
fk_article (entero) fk_tag (entero)
No hay ningún problema en el uso de muchos a muchas relaciones. A menudo se requiere.
Y sí, no es posible crear una relación de muchos a muchos, sin utilizar una tercera tabla.
Estás viendo la diferencia entre un diseño de base de datos conceptual (la relación N: N) y su realización física. No importa cómo modele su relación N: N, necesitará la Tabla de unión antes mencionada para que funcione.
No hay nada de malo en modelar una relación del mundo real tan cerca del mundo real como pueda como afirmación general. La claridad es el rey.
Cuando se trata de cualquier pregunta de rendimiento en cualquier sistema, la respuesta generalmente se reduce a "depende".
Si su problema de rendimiento está relacionado con ESCRIBIR, entonces una estructura altamente NORMALIZADA es la mejor y querrá esa tabla de unión. Terminará escribiendo mucho menos datos y eso puede acelerar sustancialmente las cosas (aunque puede quemar esa ventaja haciendo búsquedas antes de crear las inserciones). La lectura de las tablas individuales normalizadas también puede ser muy rápida.
Si su problema está relacionado con las LECTURAS analíticas, entonces una estructura DENORMALIZADA es la mejor. Las uniones pueden ser muy intensivas en rendimiento si las tablas son grandes y los índices se extienden. Sacrificarás mucho espacio para ganar mucho tiempo.
En general, desea ver los detalles de su situación y sopesar los pros y los contras de cada enfoque antes de tomar una decisión. Personalmente, siempre me ha parecido mejor enfocarme en Clarity en las etapas iniciales y refactorizar el rendimiento si descubro un problema más adelante.
¿Cómo se creó una relación de muchos a muchos sin el uso de una tabla de artículos de etiquetas? – flayto
Si tiene una relación de muchos a muchos, necesita representar la tercera tabla, no hay una alternativa sensata. Su enfoque más cercano podría ser una estructura SET en cada tabla, si su DBMS lo admite. Pero normalmente no hay mucha verificación entre tablas en tales tipos, la tabla separada es necesaria. –