Conception de table pour SQL

Question

Je espère que vous pouvez 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 j'allais essayer juste par intérêt.

Supposons que j'ai une table nommée family_surname. Dans cette table, il pourrait y avoir x nombre de family_members, disons allant de 2 personnes à 22 personnes. Comment puis-je faire référence à family_members par rapport à family_surname?

Donc j'aurais FAMILY SURNAME Smith, Jones, Brown, Taylor, etc.

Et puis Smith peut avoir 5 membres, où je voudrais enregistrer l'âge, la taille, le poids, quoi que ce soit. Jones peut avoir 8 membres - cela pourrait varier entre les familles.

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

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

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

ÉDITION Merci à tous ceux qui ont commenté - certainement des informations utiles ici, que j'apprécie. Je lis et recherche quelques éléments de SQL, et jusqu'à présent c'est assez bon. Merci encore, les gars!

Answer 1

Ce que vous demandez est 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'ID. 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 étant dit, je ne suis pas sûr que le nom soit un bon candidat pour être séparé de cette manière. Une raison de normaliser des données est de maintenir l'intégrité relationnelle. Dans ce cas, cela signifie que lorsque vous changez "Smith" en "Jones", tous les Smiths changent en même temps. Je ne pense pas que ce soit une préoccupation 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 correcte, mais pour commencer....

Décomposer le nom de la personne (prénom et nom de famille) est probablement un peu trop. À moins que vous ne supposiez que tout le monde nommé "jones" est 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, FirstName, LastName. Et s'il le faut, une table séparée pour stocker d'autres informations. Cependant, puisque la 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 à utiliser 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

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

Answer 4

Je ne veux pas vraiment que le 'nom de famille' soit listé 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 envisagiez 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 jointure juste pour trouver le nom de famille de la personne - mauvais 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 qui existe déjà ou insérer le nouveau.
  • La modification (par exemple, lorsque la femme prend le nom de famille de son mari) est une combinaison de suppression (voir ci-dessous) et d'insertion.
  • Est-ce qu'un nom de famille peut exister sans aucune personne l'ayant? Si non, il n'y a pas d'intégrité déclarative solide pour imposer cela. Au mieux, vous auriez besoin d'écrire quelques 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 "sous" la clé primaire) qui pourraient "manger" une grande partie des économies de stockage anticipées.