J'ai deux entités qui ont généralement une relation à une autre, mais dans de rares cas devraient avoir la possibilité d'être nombreux à plusieurs. Je ne veux pas rejoindre les tables avec la table intermédiaire pour chaque requête - et je suppose qu'il existe des modèles préférables pour "rares nombreux-to-plusieurs", - (peut-être avec une table supplémentaire pour M-T-M, avec des enregistrements en double ou quelque chose). Des idées?
upd. Eh bien, tout d'abord, je pense à des frais généraux potentiels avec une table intermédiaire (peut-être que je surestitez-le), le second consiste à exprimer sémantique du monde réel que les objets devraient généralement avoir une relation à plusieurs.
7 Réponses :
En général, vous ne pourrez pas éviter la table intermédiaire. Quoi que vous fassiez pour que le cas unique ne facilite que vous ne coûte que vous avez plus d'efforts pour gérer le dossier général M: N CORRECT.
Quel est le problème avec la relation beaucoup à plusieurs? C'est le moyen le plus simple de résoudre le problème et de rejoindre les tables sera très rapide si les index sont définis correctement. Et ne vous inquiétez pas du temps de codage - vous pouvez factoriser la jointure afin que vous n'ayez besoin que de l'écrire une fois. Si vous utilisez un logiciel de type LINQ, vous pouvez stocker des sous-requêtes. Si vous construisez des chaînes SQL à la main, vous pouvez toujours stocker la sous-requête en tant que chaîne constante quelque part dans votre programme.
Cependant, vous pouvez éviter la table supplémentaire en créant deux colonnes «enfant primaire» et «enfant secondaire» où l'enfant primaire n'est pas nul et que l'enfant secondaire est nullable. Si vous ne vous souciez pas de la possibilité de multiples correspondances, sélectionnez uniquement l'enfant primaire. Dans les rares cas où cela importe, sélectionnez les deux enfants.
Je vais supposer que votre question concerne les bases de données relatives à la relation relationnelle (SQL, par exemple). Si vous souhaitez modéliser la table dans un formulaire «normal», une table intermédiaire est requise. Mais, sans la restriction de la normalité, vous pouvez modéliser votre cas avec une table unique avec M * N lignes (résultat d'une jointure interne si vous aviez votre table A, une table intermédiaire et une table B. Cela peut être utile dans l'entreposage de données. Opérations, mais je ne suggérerais pas d'utiliser cette stratégie si la table aurait souvent des lignes supprimées, mises à jour ou insérées.
Si quelque chose est généralement une relation un à plusieurs mais parfois à plusieurs à plusieurs, il ne s'agit que d'une relation à plusieurs à plusieurs, pas un intermédiaire transitoire. Quel est le problème avec la table intermédiaire - je suppose que la performance ici. J'ai trouvé si vous utilisez des fichiers de données qui sont rapides à comparer (entiers par exemple) et de corriger les index, puis le modèle de plusieurs à plusieurs échelonnera de manière assez efficace. Si cela reste un problème, vous envisagez peut-être de réviser votre schéma, par exemple. Les multiples entités sont-elles vraiment identiques que les entités habituellement une à plusieurs ou si elles devraient être des tables séparées ensemble?
Un moyen d'éviter que la table de l'association est de disposer de chacune des tables principales contenant quelque chose comme un ensemble d'entrées croisées croisées dans l'autre table - supposant que votre SGBD prend en charge une telle construction. Il est infiniment moins souhaitable pour de nombreuses raisons, notamment qu'il est extrêmement difficile de faire appel ou de mettre à jour la liste correcte automatiquement.
Schéma de contour: P>
create table t1 (id integer, xref_t2 set(integer), ...other columns...); create table t2 (id integer, xref_t1 set(integer), ...other columns...);
Une relation "rare plusieurs à plusieurs" est toujours une relation M: M et doit être modélisée correctement. Cela implique de créer une table intermédiaire ou d'association reliant ensemble les deux tables. Vos requêtes seront légèrement plus complexes mais impliquent une jointure supplémentaire. Mais vous aurez la satisfaction et l'admiration de vos pairs que vous avez correctement modélisé vos tables :)
Randy
Malheureusement, il est plutôt plus probable que ses pairs s'opposent à la complexité supplémentaire parce qu'ils préfèrent ne pas avoir à penser avec précision. La satisfaction de la modélisation sera précisément pour l'OP et pour l'OP uniquement.
Eh bien, tout d'abord, je pense à des frais généraux potentiels avec une table intermédiaire (peut-être que je surestime le surestimer)
Je pense que vous faites. Les jointures indexées sont les bases de données particulièrement bonnes.
La seconde consiste à exprimer une sémantique du monde réel que les objets généralement devraient avoir une relation à plusieurs.
Eh bien, c'est la question que nous ne pouvons pas répondre sans exemple plus concrète: comment la nature de la relation habituelle à une autre diffère de la «cas spéciale» plusieurs à plusieurs? Lorsque plusieurs à plusieurs se produisent, la relation est-elle différente entre un des mappages en particulier, et tout le reste? Si c'est le cas, il peut être logique d'avoir une référence distincte à distance pour la mappage unique, avec une table de jointure pour les autres.
mais si c'est juste le même type de relation - juste un qui habituellement mais pas toujours est un à plusieurs - alors il est toujours une relation à plusieurs à plusieurs, et la modélise tout autre chemin va faire une tige pour votre propre dos. Vous vous retrouveriez avec chaque requête qui doit vérifier la relation unique d'abord, puis vérifier les nombreux à plusieurs aussi bien , qui serait plus de frais généraux et serait une requête beaucoup plus compliquée à écrire.
Qu'est-ce qui ne va pas avec exactement la modélisation de la relation (en utilisant une table intermédiaire)?