J'ai actuellement une base de données avec deux tables appelées Articles et Tags. Afin de permettre aux articles d'être dans plusieurs catégories j'ai une relation de plusieurs à plusieurs. Est-ce une erreur d'avoir un tel design en termes de performance? ou devrais-je supprimer la relation entre ces deux tables et ajouter une troisième table en tant que pont (articlesTags)?relation plusieurs-à-plusieurs dans la conception de base de données
Il n'y a rien de mal à avoir une relation plusieurs-à-plusieurs, vous aurez juste besoin de créer un Junction Table (ce qui ressemble à ce dont vous parlez avec articlesTags) pour faciliter cette relation.
Il n'y a pas de problème avec une relation plusieurs-à-plusieurs si c'est ce que requièrent les données, mais vous aurez besoin d'une troisième table pour la représenter.
Je dirais "vous aurez besoin d'une troisième table." – Dave
Une relation plusieurs-à-plusieurs existe dans un modèle relationnel, c'est juste une abstraction de l'esprit. Lorsque vous le mettre en œuvre, il y aura une table de articles_to_tags où vous aurez:
fk_article (ENTIER) fk_tag (ENTIER)
Il n'y a pas de problème à l'aide de nombreux à de nombreuses relations. C'est souvent nécessaire.
Et oui, il n'est pas possible de créer une relation many to many, sans utiliser une troisième table.
Vous voyez la différence entre une conception de base de données conceptuelle (la relation N: N) et sa réalisation physique. Peu importe la façon dont vous modélisez votre relation N: N, vous aurez besoin de la table de jonction susmentionnée pour que cela fonctionne.
Il n'y a rien de mal à modéliser une relation du monde réel aussi proche du monde réel que vous le pouvez en général. La clarté est roi.
Quand il s'agit de n'importe quelle question de performance dans n'importe quel système, la réponse se résume habituellement à "ça dépend".
Si votre problème de performance est lié à WRITES, alors une structure hautement NORMALISÉE est la meilleure et vous aurez besoin de cette table de jonction. Vous finirez par écrire beaucoup moins de données et cela peut accélérer considérablement les choses (bien que vous puissiez brûler cet avantage en effectuant des recherches avant de créer les insertions). La lecture des tables normalisées individuelles peut être très rapide aussi.
Si votre problème est lié aux LECTURES analytiques, alors une structure DENORMALISÉE est la meilleure. Les jointures peuvent être très performantes si les tables sont grandes et les indices étalés. Vous allez sacrifier beaucoup d'espace pour gagner beaucoup de temps.
En général, vous voulez examiner les spécificités de votre situation et peser le pour et le contre de chaque approche avant de décider d'une solution. Personnellement, j'ai toujours trouvé préférable de se concentrer sur Clarity dans les premières étapes et de refactoriser pour la performance si je découvre un problème plus tard.
Comment avez-vous créé une relation plusieurs-à-plusieurs sans l'utilisation d'une table articlesTags? – flayto
Si vous avez une relation plusieurs-à-plusieurs, vous avez besoin de la troisième table à représenter - il n'y a pas d'alternative raisonnable. Votre approche la plus proche pourrait être une structure SET dans chaque table - si votre SGBD le supporte. Mais il n'y a généralement pas beaucoup de vérification inter-tables sur ces types - la table séparée est nécessaire. –