Comment stocker des détails de profils à valeurs multiples?

Question

J'ai beaucoup de champs qui sont multi-évalués et je ne sais pas comment les stocker? si je fais 3NF alors il y a beaucoup de tables. Par exemple: Nationalité.

Une personne peut avoir une nationalité simple ou double. si dual cela signifie que c'est un à plusieurs. Donc, je crée une table utilisateur et une table user_nationality. (il y a déjà une table de consultation de nationalité). ou je pourrais mettre les deux nationalités dans la même rangée comme "Américain, Allemand" puis le désérialiser lors de la course. Mais alors je ne sais pas si je peux chercher ceci? comme si je cherchais seulement les Allemands apparaîtront-ils?

Ceci est un exemple, j'ai plus de 30 champs qui sont multi-évalués, donc je suppose que je ne vais pas créer 61 tables pour cela? 1 table utilisateur, 30 tables de recherche pour contenir les recherches de chaque élément à valeurs multiples et 30 tables pour contenir les valeurs user_ pour les éléments à valeurs multiples? Vous devez également garder à l'esprit que certains champs à valeurs multiples se regroupent comme "collèges que j'ai étudiés", il a un groupe de champs tels que le nom de l'université, le type de diplôme, la ligne de temps, etc Et un utilisateur peut avoir 1 à plusieurs d'entre eux. Donc je suppose que je peux créer une table séparée pour cela comme user_education avec ces champs, mais laisse supposer que l'un de ces champs est également fixe liste multi-valuée comme campus universitaires que j'ai visités alors nous finirons dans une chaîne interminable de tables FK Ce n'est pas un bon design pour les réseaux sociaux car l'objectif est de mettre autant de données dans le moins de tables possible pour la performance.

Answer 1

La solution simple est d'arrêter d'utiliser une table SQL. C'est ce à quoi NoSQL est destiné. Découvrez CouchDB ou Mongo. Chaque valeur peut être stockée en tant que structure complète - donc tout ce problème pourrait être réduit à une seule table (pas vraiment). L'inconvénient de la plupart des solutions basées sur SQL est qu'elles seront lentes. Soit lent lors de l'extraction d'un seul utilisateur - une instruction JOIN massive ne sera pas exécutée rapidement ou lente lors de la recherche (si vous décidez de stocker ces valeurs en série).

Answer 2

Si vous devez continuer à utiliser SQL, vous devez créer ces tables. vous devrez décider jusqu'à quel point vous êtes prêt à aller, et imposer des limites au système (comme ne pouvoir spécifier qu'un campus).

En ce qui concerne la nationalité, si vous n'avez besoin que de deux nationalités (scénario le plus défavorable), vous pouvez envisager un second champ de nationalité (Nationalité et Nationalité2) pour en tenir compte. Bien sûr, cela ne s'applique qu'aux champs avec un petit nombre maximum de valeurs différentes.

Answer 3

Si votre table d'utilisateur a beaucoup d'attributs liés, alors une possibilité est de créer une table d'attributs avec des rangées comme (user_id, attribute_name, attribute_value). Vous pouvez stocker tous vos attributs dans une table. Vous pouvez utiliser cette table pour extraire des attributs pour des utilisateurs donnés, également effectuer une recherche par nom d'attribut et par valeur.

Answer 4

Vous pouvez également consulter ORM qui maquettera automatiquement vos objets dans une base de données.
http://en.wikipedia.org/wiki/List_of_object-relational_mapping_software#PHP

Answer 5

Ceci est un exemple, j'ai plus de 30 champs qui sont à plusieurs valeurs, donc je suppose que je ne créerons pas 61 tables pour cela?

Vous avez raison que 61 est le nombre maximum de tables, mais en réalité, il y aura probablement moins, prenez votre propre exemple:

« collèges je l'ai étudié à »

« campus universitaires i visité »

dans ce cas, vous aurez probablement avoir une table « collage », donc il y aurait quatre tables dans cette mise en page, et non pas cinq. Je dirais que n'ayez pas peur d'utiliser beaucoup de tables si l'ensemble de données que vous modélisez est grand - assurez-vous juste de garder une ERD à jour pour ne pas vous perdre! Aussi, ne vous laissez pas trop attraper dans le paradigme de la «table de liens» - les «tables de liens» peuvent être des «entités» dans leurs propres droits, par exemple vous pourriez penser à la table de liens «collèges que j'ai étudiés» "Collage inscriptions" à la place, donnez-lui sa propre clé primaire, et stockez chaque fois que vous payez vos frais de cours en tant que lignes dans un tableau (lié) "collage des paiements d'inscription".