Conception de table pour SQL

Question

J'espère que vous pourrez m'aider ici - j'ai une question sur la conception d'une table SQL. Je sais comment écrire dans une base de données et exécuter des requêtes en utilisant C#, mais je n'ai jamais vraiment eu à en concevoir une. Alors j'ai pensé que je pourrais essayer juste par intérêt.

Supposons que j'ai une table nommée famille_nom. Dans cette table, il pourrait y avoir un certain nombre de membres de la famille, allant de 2 personnes à 22 personnes. Comment puis-je référencer les membres de la famille par rapport au nom de famille?

Donc j'aurais NOM DE FAMILLE Smith, Jones, Brown, Taylor, etc.

Et puis Smith peut avoir 5 membres, où j'aimerais enregistrer l'âge, la taille, le poids, etc. Jones peut avoir 8 membres - cela pourrait varier d'une famille à l'autre.

Je ne veux pas vraiment que 'nom de famille' soit répertorié 8 fois pour chaque membre - idéalement, la ligne de nom de famille ferait référence (ou pointerait d'une certaine manière) vers une ligne correspondante dans une autre table. Et c'est là que j'ai des problèmes!

J'espère que je suis clair; comme je l'ai dit, je suis simplement intéressé, mais j'aimerais savoir comment faire cela avec deux tables.

Quoi qu'il en soit, merci pour votre aide, je l'apprécie.

MODIFIER Merci à tous ceux qui ont commenté - certainement des informations utiles ici, que j'apprécie. J'étudie et recherche quelques éléments de SQL, et jusqu'à présent c'est plutôt bien. Merci encore, les gars!

Answer 1

Vous demandez une question sur la normalisation. La table ressemblerait à :

Créer une table nom (
    SurnameID int,
    Surname varchar(255)
)

Les autres tables feraient référence au nom en utilisant l'identifiant. De plus, vous voulez probablement que surnameid soit unique, une clé primaire et auto-incrémentée. Ce sont des sujets plus avancés.

Cela dit, je ne suis pas sûr que le nom soit un bon candidat à diviser de cette manière. Une raison de normaliser les données est de maintenir l'intégrité relationnelle. Dans ce cas, cela signifie que lorsque vous changez "Smith" en "Jones", tous les Smith changent en même temps. Je ne pense pas que ce soit un problème dans votre cas.

Answer 2

Oui, la réponse précédente sur l'apprentissage de la normalisation des bases de données est probablement exacte mais pour commencer....

Décomposer le nom de la personne (prénom et nom de famille) est sûrement un peu trop. À moins que vous ne supposiez que tous ceux qui s'appellent "Jones" sont TOUS liés. Pensez à chaque table comme une entité/objet et essayez de les connecter à des "objets" du monde réel autant que possible. Puisqu'une personne a besoin à la fois du prénom et du nom de famille (au minimum) pour les identifier de manière unique, ils ne devraient pas être normalisés de cette manière.

Dans le scénario que vous avez décrit, vous devriez avoir une table Persons qui contient PersonId, Prénom, Nom de famille. Et si besoin, une table séparée pour stocker d'autres informations. Cependant, étant donné qu'une personne ne peut avoir qu'une seule taille, poids, âge, etc... ceux-ci devraient être stockés dans la table Persons.

Par conséquent, vous n'avez vraiment besoin que d'une seule table ici. À moins que vous ne commenciez à inclure des numéros de téléphone, des adresses, etc.

Answer 3

La décomposition peut être faite comme suit

1. CREATE TABLE SURNAMES(INT ID, SURNAME VARCHAR2(200))
2. CREATE TABLE DETAILS(INT ID, FOREIGN KEY(SURNAME_ID) REFERENCES SURNAMES(ID), PARAM1, PARAM2 .....)

Un croquis approximatif de la décomposition est le suivant

Obtenez la liste des attributs (NOM, PARAM1, PARAM2, ....). En fonction de la liste des attributs, les clés suivantes peuvent être déduites : 1. (NOM) 2. (PARAM1, PARAM2...) Une table distincte est créée pour chaque ensemble de clés

Answer 4

Je ne veux pas vraiment que le 'nom de famille' soit répertorié 8 fois pour chaque membre

Pourquoi? Avez-vous mesuré sur des quantités de données réalistes et déterminé que c'est en fait un problème?

À moins que vous n'ayez l'intention d'avoir des données supplémentaires spécifiques au nom de famille (et indépendantes des personnes ayant ce nom de famille), il n'y a rien de mal à ce que le nom de famille ne soit pas dans sa propre table. Vous ne violez aucune forme normale.

En fait, ce que vous proposez peut être une très mauvaise idée, pour les raisons suivantes :

• Tout d'abord, vous auriez besoin d'une JOIN juste pour trouver le nom de famille de la personne - néfaste pour les performances.
• Cela complique (et ralentit) l'insertion/modification/suppression des personnes.
  • Lors de l'insertion d'une nouvelle personne, vous devriez rechercher dans la table des noms de famille pour décider si vous pouvez "réutiliser" celui existant ou insérer le nouveau.
  • La modification (par exemple, lorsque une épouse prend le nom de famille de son mari) est une combinaison de suppression (voir ci-dessous) et d'insertion.
  • Un nom de famille peut-il exister sans qu'aucune personne ne le porte? Si non, il n'y a pas de bonne intégrité déclarative pour imposer cela. Au mieux, vous devriez écrire des déclencheurs.
• Vous pourriez ne pas finir par économiser beaucoup d'espace après tout - la table supplémentaire aura ses propres frais de stockage (comme l'index "en dessous" de la clé primaire) qui pourraient "manger" une grande partie des économies de stockage anticipées.