Quoi de mieux - de nombreuses petites tables ou une grande table?
J'ai une base de données qui stockera les profils des individus. Ces individus ont environ 50 champs possibles.
Certains sont des choses courantes comme, prénom, nom de famille, e-mail, numéro de téléphone.
D'autres sont des choses comme les loisirs, les compétences, les intérêts
Certains sont la taille, le poids, la couleur de la peau.
Chacun de ces groupes est utilisé par le système à différents moments. Pour ce qui est de pouvoir négocier via la base de données, je préférerais avoir 7 tableaux d'environ 8 champs chacun. Quelle est la meilleure pratique à faire?
EDIT: Les données vont être utilisées dans un moteur de recherche, pour trouver des correspondances de profil. Est-ce que cela affecte ce que je fais?
Il est difficile à dire et est basé sur les besoins de l'application. Je dirais d'examiner Normalisation de la base de données car cela vous montrera comment normaliser la base de données et en ce qu'elle devrait faire la lumière sur ce que vous souhaitez séparer dans leurs propres tables, etc.
Je suis avec le camp Normalize.
Voici quelques conseils pour vous aider à démarrer:
Commencez par un processus pour attribuer un identifiant unique arbitraire à chaque "personne". Appelez cela le PersonId ou quelque chose comme ça. Cet identifiant est appelé clé de substitution. Le seul but d'une clé de substitution est de garantir une relation 1 à 1 entre elle et une personne réelle dans le monde réel. Utilisez la clé de substitution lorsque vous associez la valeur d'un autre attribut à une "personne" dans votre base de données.
Lorsque vous développez la disposition de votre base de données, vous pouvez également trouver des clés de substitution nécessaires (ou au moins utiles) pour certains autres attributs.
Regardez chaque attribut que vous souhaitez gérer. Posez la question suivante: une personne donnée n'a-t-elle qu'une seule valeur pour cet attribut?
Par exemple, chaque personne a exactement une "date de naissance". Mais comment peuvent-ils avoir des "hobbies"? Probablement zéro à plusieurs. Les attributs à valeur unique (par exemple, la date de naissance, la taille, le poids, etc.) peuvent entrer dans une table commune avec PersonId comme clé. Le nombre d'attributs dans chaque table ne devrait pas être un problème à ce stade.
Les attributs à valeurs multiples tels que Hobby nécessitent un traitement légèrement différent. Vous souhaiterez peut-être créer des tables distinctes pour chaque attribut à valeurs multiples. En utilisant Hobbies comme exemple, vous pouvez créer le tableau suivant PersonHobby(PersonId, Hobby). Une ligne de ce tableau peut ressembler à: (123, "Stamp Collecting"). De cette façon, vous pouvez enregistrer autant de loisirs que nécessaire pour chaque personne, un par ligne. Faites de même pour "Intérêt", "Compétence", etc.
S'il existe un certain nombre d'attributs à valeurs multiples où la combinaison de PersonId + Hobby Ne détermine rien d'autre (c'est-à-dire que vous n'avez rien d'intéressant à enregistrer sur cette personne qui fait ce "Hobby" ou "Intérêt" ou " Skill "), vous pouvez les regrouper dans une table Attribute-Value ayant une structure similaire à PersonAV(PersonId, AttributeName, Value). Ici, une ligne pourrait ressembler à: (123, "Hobby", "Stamp Collecting").
Si vous suivez cette route, il est également judicieux de remplacer la clé AttributeName dans la table PersonAV par une clé de substitution et de créer une autre table pour associer cette clé à sa description. Quelque chose comme: Attribute(AttributeId, AttributeName). Une ligne de ce tableau ressemblerait à quelque chose comme (1, "Hobby") Et une ligne PersonAV correspondante pourrait être (123, 1, "Stamp Collecting"). Ceci est généralement fait pour que si vous avez besoin de savoir quels AttributeNames sont valides dans votre base de données/application, vous avez un endroit pour les rechercher. Réfléchissez à la façon dont vous pourriez valider si "Intérêt" est une valeur valide pour AttributeName ou non - si vous n'avez enregistré aucune personne ayant ce AttributeName alors il n'y a aucun enregistrement de ce AttributeName sur votre base de données - comment savoir si elle doit exister ou non? Regardez bien dans la table Attribute!
Certains attributs peuvent avoir plusieurs relations et cela aussi influencera la normalisation des tables. Je n'ai vu aucune de ces dépendances dans votre exemple, alors considérez ce qui suit: Supposons que nous ayons un entrepôt plein de pièces, le PartId détermine son WeightClass, StockCount et ShipCost. Cela suggère une table quelque chose comme: Part(PartId, WeightClass, StockCount, ShipCost). Cependant, s'il existe une relation entre des attributs non clés, ils doivent être éliminés. Par exemple, supposons que WeightClass détermine directement ShipCost. Cela implique que WeightClass seul suffit pour déterminer que ShipCost et ShipCost doivent être éliminés de la table Part.
La normalisation est un art assez subtil. Vous devez identifier les dépendances fonctionnelles qui existent entre tous les attributs de votre modèle de données afin de le faire correctement. Le simple fait de proposer les dépendances fonctionnelles demande un peu de réflexion et de considération - mais il est essentiel de parvenir à la conception appropriée de la base de données.
Je vous encourage à prendre le temps d'étudier un peu plus la normalisation avant de créer votre base de données. Quelques jours passés ici seront plus que rentables sur la route. Essayez de faire des recherches sur Google/Wikipedia pour "Dépendance fonctionnelle", "Normalisation" et "Conception de base de données". Lisez, étudiez, apprenez, puis construisez-le correctement.
Les suggestions que j'ai faites concernant la normalisation de la conception de votre base de données ne sont qu'un indice de la direction à prendre. Sans avoir une bonne compréhension de toutes les données que vous essayez de gérer dans votre application, tout conseil donné ici doit être pris avec un "grain de sel".
Je recommanderais quelques tableaux. La sur-normalisation est difficile à gérer et vous finiriez par écrire des requêtes complexes qui aboutiraient à des performances lentes.
Normalisez uniquement lorsque cela est absolument nécessaire et pensez en termes logiques. Avec les informations limitées que vous avez fournies ci-dessus, je choisirais trois tableaux:
Tableau 1: PersonalDetails Tableau 2: Activités Tableau 3: Divers
Il existe d'autres techniques pour accélérer les performances, comme le clustering, etc., que vous pouvez utiliser en fonction de vos besoins.
D'après ce que vous avez décrit, je diviserais certainement cela en plusieurs tableaux. Cependant, je ne diviserais pas sur un nombre arbitraire de colonnes, essayez plutôt de penser à des collections logiques de colonnes qui constituent une entité ou correspondent aux modèles d'accès que vous allez utiliser pour accéder aux données
OMI, il est plus important de se soucier de la qualité des données stockées que du nombre de tables dont vous avez besoin.
Par exemple, avez-vous besoin de suivre les modifications? Si John avait 5'2 "en janvier 2007 et 5'11" en octobre 2010, voulez-vous savoir? Si c'est le cas, vous devrez séparer la personne de la hauteur en deux tables.
Que diriez-vous des passe-temps - sont-ils autorisés à avoir seulement 3 passe-temps? Peuvent-ils en avoir plus/moins? Est-ce quelque chose que vous souhaiteriez interroger à l'avenir? Si oui, vous avez besoin d'une table séparée.
Vous devriez vous renseigner sur la conception et la normalisation de la base de données (il existe plusieurs excellents fils de discussion sur ce site lui-même).
À moins que chaque personne ait le même nombre de passe-temps (IE tout le monde a 2 passe-temps répertoriés), cela devrait être normalisé.
Les champs qui sont toujours 1 à 1 avec la personne doivent être dans le même tableau. L'âge par exemple. Aucune personne n'aura deux âges différents.
Il n'y a pas de réponse correcte à cette question, car elle dépend en grande partie du moment et de la manière dont vous allez utiliser vos données, de la fréquence à laquelle elles changeront et du volume d'utilisation de la base de données.
Ce que je ferais personnellement serait d'organiser vos données en entités logiques et de créer des tables basées sur ces entités. C'est au moins par là que je commencerais.
Il n'y a pas d'organisation de base de données 100% correcte, il n'y en a qu'une qui soit assez bonne pour vos besoins. Si vous ne prévoyez pas de dépasser les capacités d'un seul bon serveur de base de données à l'avenir, normalisez les données et utilisez de nombreuses contraintes telles que les clés étrangères, les suppressions en cascade, etc., ce qui rendra votre base de données agréable à travailler. D'un autre côté, si vous regardez les bases de données de nombreuses applications qui ont des milliards de requêtes, vous constaterez qu'elles renoncent à beaucoup de ces subtilités au nom des performances et de l'évolutivité.
de nombreuses petites tables, c'est-à-dire que la normalisation est la meilleure ici. il offre une flexibilité, réduit la redondance et une meilleure organisation de la base de données.