2010-11-24 27 views
1

J'ai un site avec des utilisateurs que je veux que les utilisateurs puissent identifier leurs appartenances ethniques. Quelle est la meilleure façon de modéliser ceci s'il n'y a qu'un seul niveau de hiérarchie?Modélisation des données: ethnies avec relation parent-enfant?

Solution 1 (tableau simple):

Ethnicity 
- Id 
- Parent Id 
- Name 

Solution 2 (deux tables):

Ethnicity Group 
- Id 
- Name 

Ethnicity 
- Id 
- Ethnicity Group Id 
- Name 

Je vais utiliser cela pour que les utilisateurs peuvent rechercher d'autres utilisateurs en fonction de l'appartenance ethnique. Laquelle des deux approches fonctionnera mieux pour moi? Y a-t-il une autre approche que je n'ai pas envisagée? J'utilise MySQL.

+1

S'il n'y a qu'un seul niveau de hiérarchie, comment peut-il y avoir EthnicityGroup? –

Répondre

1

Eh bien, il y a une telle chose comme un groupe d'ethnicité dans le monde réel, donc vous avez besoin de deux tables, pas un. Le monde réel a trois niveaux (le plus haut serait Race), mais je comprends que cela ne soit pas nécessaire ici. Si vous écrasez les trois niveaux en deux, vous devez être prudent et les disposer correctement au début. Cependant, ils seront vulnérables aux personnes disant qu'ils veulent la vraie chose, et vous devrez peut-être la changer, ou changer la structure pour s'adapter plus dedans ... beaucoup plus de travail plus tard).

Si vous le faites correctement, comme dans le monde réel, ce problème est éliminé. Faites-moi savoir si vous voulez Race, et je vais changer le modèle.

Les tables sont beaucoup trop petites et les clés sont trop significatives pour y ajouter des colonnes Id-iot; laissez-les comme de simples clés relationnelles, sinon vous perdrez la puissance du moteur relationnel. Si vous voulez vraiment des clés étroites, utilisez un code Ethnicity CHAR (2) plutôt qu'un NUMERIC (10,0) ou un nombre sans signification.

Link to Ethnicity Data Model (plus la réponse à votre autre question)

Link to IDEF1X Notation pour ceux qui ne sont pas familiers avec la modélisation relationnelle standard.

+0

@SONewbie. Merci. Vous n'avez pas re re si vous voulez la race (3 niveaux) ou 2 niveaux. – PerformanceDBA

+0

Je suis encore en train de contempler des choses. Peut-être cela suffit-il à mes besoins: «Asiatique, Japonais», «Asiatique, Coréen», etc. Peut-être n'ai-je pas vraiment besoin de ce concept de hiérarchie. Pas encore sûr. Toujours penser à la façon dont les données seront utilisées. Si j'ai besoin de la hiérarchie, je pense que je n'aurai besoin que de deux. – StackOverflowNewbie

+0

@SONewbie. Modèle de données mis à jour. – PerformanceDBA

0

S'il n'y a rien de tel qu'un «groupe ethnique» dans le monde réel, je vous suggère de ne pas en introduire un dans votre modèle de données.

Toutes les requêtes que vous pouvez faire avec le second vous pouvez aussi faire avec le premier, parce que vous pouvez simplement sélectionner FROM ethnicity AS e1 JOIN ethnicity AS es ON (e2.ethnicity_id = e1.parent_id).

+0

"Asiatique" est un groupe, "Japonais" est l'ethnicité réelle ??? – StackOverflowNewbie

+1

Je n'ai jamais entendu quelqu'un dire "les gens du groupe ethnique asiatique" mais dans ce cas, allez-y et créez votre tableau "Ethnicity Group". Votre structure de base de données devrait modéliser la réalité. – AndreKR

0

Je ne veux pas être gêné, mais qu'allez-vous faire avec les personnes de descendance mixte? Je pense que le mieux que vous pouvez espérer est une simple énumération à un seul niveau, comme le genre de choses que vous obtenez sur les formulaires de recensement (par exemple «Noir», «Blanc», «Asiatique», «Hispanique», etc.). Ce n'est pas idéal, mais cela permet aux gens de s'identifier assez facilement. Des concepts comme la race et l'ethnie sont assez laineux sans essayer de créer des hiérarchies supplémentaires (largement dépourvues de sens) au-dessus d'eux, alors mon instinct est de garder les choses simples.

+0

Les utilisateurs seront en mesure de sélectionner 0 ou plusieurs ethnies. – StackOverflowNewbie