Database Design: simplifier beaucoup à beaucoup

Question

Dire que j'ai les tableaux suivants:

• personne (person_id, nom)
• ethnicité (ethnicity_id, nom)
• person_ethnicity (person_id, ethnicity_id)

Cela me permettrait de définir un person pour avoir 0 ou plus ethnicity ET un ethnicity pour avoir 0 ou plus person à travers le person_ethnicity tableau. Maintenant, disons que j'ai beaucoup de ces tables de type "ethnicité" où je dois faire la même relation plusieurs à plusieurs avec la table person. Le nombre de mes tables va augmenter rapidement.

Est-ce une bonne idée d'avoir une table comme ceci:

• foo (person_id, other_table_name, other_table_pk)

Un exemple:

================================================= 
| person_id | other_table_name | other_table_pk | 
================================================= 
| 1   | ethnicity  | 1    | 
------------------------------------------------- 

je perds referencial l'intégrité de cette façon, mais rendrait la modélisation beaucoup plus facile, je pense. Cette approche est-elle une bonne idée ou une idée horrible et horrible?

(Aussi, est-il un nom propre pour l'approche que je décrit ci-dessus?)

Answer 1

Je ne vois pas le besoin. Beaucoup de tables ne posent aucun problème, et vous brisez beaucoup de 'règles' en le faisant comme ça. Il suffit d'aller avec le many-to-many, si vous en avez besoin. En l'utilisant de cette façon, vous devriez faire toutes sortes de choses délicates. En outre, vous ne pouvez rien faire avec des clés étrangères (contraintes) et des tonnes d'autres problèmes. Et pour quoi? "moins de tables". Je ne vois aucun avantage en ce que: D

Il suffit de ne pas serait mon conseil: D

Answer 2

Si vous avez beaucoup de nombreux à-plusieurs dans votre modèle, comme votre exemple d'origine ethnique, vous n'ont pas d'autre choix que de les modéliser correctement comme l'exige l'idiome relationnel.

Je ne pense pas que votre design soit une bonne idée. La liaison aux noms de table et de colonne n'est pas effectuée en Java; Je ne connais pas d'autres langues.

Obtenez une pelle; se rendre au travail. Modélisez votre problème tel qu'il existe en utilisant l'idiome relationnel ou trouvez autre chose. Peut-être qu'une solution NoSQL comme un objet ou une base de données graphique est une meilleure idée dans votre cas.

Answer 3

Puisque vous posez la question d'un point de vue théorique, je vais vous donner une réponse dans le même sens.

Votre situation est très similaire à celle d'un système d'étiquettes. Et heureusement pour vous, la communauté MySQL offre un excellent article wiki sur TagSchema via Forge.

En outre, vous devriez envisager de chercher SO pour des questions similaires, car il a été asked et asked et asked.Certains d'entre eux fournissent un aperçu intéressant de la question. Surtout What tag schema(s) are the most efficient/effective? et la réponse sur la fabrication Collection Tags qui détiennent Tag Sets.

Answer 4

Votre solution ferait exploser votre table "foo".

Imaginez que vous avez 1000 personnes. alors chaque personne a un minimum de 2 ethnies.

alors vous avez une table de nationalité et chaque personne a aussi au moins 1,5 nationalités.

puis un genre où chaque personne a un minimum de 1 genre ce qui résume déjà jusqu'à 4500 entrées.

maintenant disons que votre table de personnes se développe à environ 50000 personnes.

cela fera déjà 225000 entrées dans votre table "foo". Maintenant que vos tables sont remplies, vous faites une requête pour rejoindre les personnes avec foo et seulement l'origine ethnique pour obtenir les ethnies de toutes les personnes et votre serveur fonctionnera très longtemps parce que vous rejoignez une table de 50000 avec une table de 225000 et la fin rejoint une petite table.

J'espère donc que je l'ai fait clairement pourquoi il est pas une bonne idée de faire une telle mise en page