Relations un à un impliquant plusieurs tables

Question

Dites,

J'ai 3 tables.

User qui contient des informations de base sur les utilisateurs.

SectionA qui contient plus d'informations sur l'utilisateur.

SectionB qui contient également plus d'informations sur l'utilisateur. Il ne peut y avoir qu'une seule donnée SectionA et SectionB pour chaque utilisateur.

Mon idée était de créer un design de table comme ceci:

id name section_a_id section_b_id 
1 matt 1    1 

Le problème est, section_a_id et section_b_id ne peut pas être auto incrémenté car ils ne sont pas les clés primaires.

donc j'ai essayé une approche différente et a décidé que la clé primaire id dans User devrait être une clé étrangère qui fait référence à section_a_id et section_b_id`. Mais je suis incapable de le faire puisque mysql ne permettra qu'une référence à une table.

Alors, comment dois-je aborder cette situation?

Answer 1

S'il s'agit d'une relation un à un, il sera toujours plus facile de combiner les trois tables dans une grande table, avec des colonnes nullables pour les tables de section.

Quelques points positifs que je peux voir pour cette approche:

• plus facile insérer, mettre à jour et supprimer des opérations.
• Récupération plus rapide des données lorsqu'il y a moins de jointures à utiliser.
• Moins indexe l'espace, car vous indexez la clé primaire pour une table au lieu de trois tables.

Answer 2

Il semble que vous ayez:

• 1-n relation utilisateur-SectionA
• 1-n relation utilisateur-SectionB

donc les clés étrangères doivent être dans les tableaux SectionA et SectionB et ils doivent être la clé primaire de la table utilisateur.

Answer 3

Il ne peut y avoir qu'une seule donnée SectionA et SectionB pour chaque utilisateur.

Cela soulève la question de savoir pourquoi vous stockez les données dans différents tableaux. C'est parfois une bonne chose à faire - différents utilisateurs peuvent être dans des tables différentes.

Une solution est d'avoir la clé primaire de SectionA et SectionB une référence étrangère à la UserId. Oui, c'est autorisé. Une autre solution consiste à avoir les sectionA_id et sectionB_id dans le tableau users. Vous pouvez ensuite avoir un identifiant auto-incrémenté dans chacune des tables référencées.

Answer 4

utilisations rares pour 1: 1

• Vous avez vraiment trop de colonnes;
• La table est énorme et vous ne voulez pas ALTER la table pour en ajouter plus;
• L'une des tables est généralement facultative et vous utilisez LEFT JOIN pour obtenir des valeurs nulles.

REDRESSEMENT quelques idées fausses AUTO_INCREMENT

• La colonne ne doit pas être le PRIMARY KEY, ni même UNIQUE; il suffit d'être la première colonne d'un index.
• Vous n'avez avoir à avoir une colonne AUTO_INCREMENT du tout. Il est souvent préférable d'utiliser une colonne PK (ou une combinaison de colonnes) «naturelle» qui est intrinsèquement UNIQUE.

Lors de la construction d'une paire de 1: 1 tables, c'est une façon de le faire

1. construire la première table avec une PRIMARY KEY qui est AUTO_INCREMENT.
2. Construire la seconde table avec un PRIMARY KEY identique à l'autre, mais pas AUTO_INCREMENT.
3. Lors de l'insertion d'une ligne, utilisez LAST_INSERT_ID() pour obtenir l'ID.
4. Utilisez cette valeur pour spécifier explicitement l'ID de la seconde table.