J'ai actuellement une base de données avec deux tables appelées articles et tags. Afin de permettre aux articles dans plusieurs catégories, j'ai un grand nombre de relations. Est-ce une erreur d'avoir un tel design en termes de performance? ou devrais-je supprimer la relation entre ces deux table et ajouter une troisième table en tant que pont (ArticleTags)?
5 Réponses :
Il n'y a aucun problème à avoir une relation à plusieurs à plusieurs, si c'est ce que les données nécessitent, mais vous voudrez que la 3ème table la représente.
Je dirais "tu auras besoin d'une troisième table."
Il n'y a rien de tort intrinsèquement avec une relation nombreuses à plusieurs, vous aurez juste besoin de créer un Table de jonction (qui ressemble à ce qu'il semble vous référant à articletstags ) pour faciliter cette relation.
Également appelé tableau d'intersection.
Je veux une abstraction sensible pour cela. Cette table de jonction auto-créée et autogérée, Malarkey, a continué trop longtemps.
@APC ou une table de jointure (au moins en JPA)
Oh, et selon Wikipedia, la table de référence croisée, la table de pont, la table de joints, la table de cartes, la table d'intersection, la table de liaison, le résolveur, la table de liaison, la table de jumelage, la table pivot ou la table d'association. Je ne peux pas avoir trop de noms que je suppose: p
@Bartvanheukelom - Merci: Je vais mémoriser cette liste pour la prochaine fois où je dis "Table d'intersection" et obtenez un look vierge en réponse. Quant à la "table de jointure", n'aimez pas ce terme. C'est une base de données relationnelle, ils rejoignent tous des tables (bien adhérentes).
Je pense que la table de l'association est la plus claire de son intention, et beaucoup à plusieurs résolveur a le son le plus hollywoodien :)
Une relation à plusieurs à plusieurs existe dans un modèle relatinique, c'est juste une abstraction de l'esprit. Lorsque vous l'implémenterez, il y aura une table Article_To_Tags où vous aurez:
fk_article (entier) fk_tag (entier)
Il n'y a aucun problème à utiliser beaucoup dans de nombreuses relations. Il est souvent nécessaire.
Et oui, il n'est pas possible de créer un grand nombre de relations à de nombreuses relations, sans utiliser de 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 le faire fonctionner.
Il n'y a rien de mal à modéliser une relation réelle mondiale aussi proche du monde réel que possible en tant que déclaration générale. La clarté est roi.
En ce qui concerne toute question de performance dans n'importe quel système, la réponse se résume généralement à "cela dépend".
Si votre problème de performance est lié à des écrires, une structure hautement normalisée est la meilleure et vous souhaiterez que la table de jonction. Vous finirez par écrire beaucoup moins de données et cela peut accélérer de manière substantielle les choses (bien que vous puissiez graver cet avantage en suivant des recherches avant de créer des inserts). La lecture des tables normalisées individuelles peut également être très rapide.
Si votre problème est lié à des lectures analytiques, une structure dénormalisée est la meilleure. Les jointures peuvent être très performantes si les tables sont grandes et les indices se sont étendus. Vous allez sacrifier beaucoup d'espace pour gagner beaucoup de temps.
En général, vous souhaitez examiner les spécificités de votre situation et peser les avantages et les inconvénients de chaque approche avant de décider d'une solution. Personnellement, j'ai toujours trouvé qu'il est préférable de mieux se concentrer sur la clarté dans les premières étapes et refacteur 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 ArticleTags?
Si vous avez une relation nombreuses à plusieurs, vous avez besoin de la troisième table pour représenter - il n'y a pas une alternative sensible. Votre approche la plus proche pourrait être une structure définie dans chaque table - si votre DBMS soutient cela. Mais il n'y a généralement pas beaucoup de vérification inter-table sur ces types - la table séparée est nécessaire.