Comment utiliser les clés étrangères avec PHP

Les colonnes de clé étrangère/les contraintes de désambiguïsation

Donc, je comprends comment créer des clés étrangères et je sais ce qu'est la
le but de la FK. Mais j'ai un problème dans la compréhension de Comment les utiliser
.

En supposant que vous faites référence à les contraintes de clé étrangère, la réponse courte serait vous suffit de ne pas les utiliser.

Et voici la longue:

Nous sommes habitués à se référer à colonnes de clés étrangères à d'autres tables. En particulier pendant le processus de normalisation, des phrases comme "user_purchase.i_id est une clé étrangère vers la items table" serait très commun. Alors que c'est un bon moyen de décrire la relation, il peut obtenir un peu floue quand on arrive à la phase de mise en œuvre.

Supposons que vous avez créé vos tables sans la FOREIGN KEY clauses:

CREATE TABLE user(
  id INT(11) NOT NULL AUTO_INCREMENT,
  username VARCHAR(50) NOT NULL,
  password VARCHAR(20) NOT NULL,
  PRIMARY KEY (id)
);

CREATE TABLE items(
  i_id INT(11) NOT NULL AUTO_INCREMENT,
  name TINYTEXT NOT NULL,
  price DECIMAL(8,2) NOT NULL,
  PRIMARY KEY (i_id)
);

CREATE TABLE user_purchase(
  i_id INT(11) NOT NULL,
  name TINYTEXT NOT NULL,
  id INT(11) NOT NULL,
);

Avis que, la relation, la clé étrangère colonnes sont encore mis en œuvre. Il y a une colonne qui fait référence à la user table (id) et un autre qui fait référence à la items table (i_id) -- mettons la name colonne de côté pour un moment. Considérons les données suivantes:

  user              user_purchase    items
| id  username |    | id  i_id |    | i_id  name            price |
| 23  john     |    | 55   10  |    |  10   chocolate bar    3.42 |
| 55  mary     |    | 70   10  |    |  33   mobile phone    82.11 |
| 70  fred     |    | 70   33  |    |  54   toothpaste       8.67 |
                    | 55   10  |    |  26   toy car          6.00 |
                    | 70   26  |

La relation est là. Il est mis en œuvre par le biais de la user_purchase table, qui contient les informations de qui a acheté quoi. Si nous étions à la requête de la base de données pour un rapport sur la question, nous voudrions faire:

select * from user_purchase p
join user u on (p.id=u.id)
join items i on (p.i_id=i.i_id)

Et comment nous pouvons utiliser la relation et la clé étrangère colonnes impliqués.

Maintenant, si nous faisons:

insert into user_purchase (id,i_id) values (23,99)

Apparemment, c'est une entrée non valide. Bien qu'il y a un utilisateur avec id=23, il n'y a pas d'élément avec i_id=99. Le SGBDR serait de permettre que cela se produise, parce que il ne savent pas mieux. Encore.

C'est là la clé étrangère contraintes entrent en jeu. En spécifiant FOREIGN KEY (i_id) REFERENCES items(i_id) dans le user_purchase définition de la table, nous avons essentiellement donner le SGBDR une règle à suivre: entrées avec i_id valeurs qui ne sont pas contenues dans le items.i_id colonne ne sont pas acceptables. En d'autres termes, alors qu'une clé étrangère colonne met en œuvre la référence, une clé étrangère contrainte applique la l'intégrité référentielle.

Noter, cependant, que le ci-dessus select ne change pas, juste parce que vous avez défini un FK contrainte. Ainsi, vous n'utilisez pas de contraintes FK, le SGBDR n', afin de protéger vos données.

Licenciements

que...si je veux plusieurs colonnes? Pourquoi n'utilisons-nous pas plusieurs étrangers
clés pour différentes colonnes de la même table?

Demandez-vous: Pourquoi voudriez-vous que? Si les deux clés étrangères sont de servir le même but, la redondance finira par obtenir en difficulté. Considérons les données suivantes:

 user_purchase                   items
| id  i_id  name           |    | i_id  name            price |
| 55   10   chocolate bar  |    |  10   chocolate bar    3.42 |
| 70   10   chocolate bar  |    |  33   mobile phone    82.11 |
| 70   33   mobile phone   |    |  54   toothpaste       8.67 |
| 55   10   toothpaste     |    |  26   toy car          6.00 |
| 70   26   toy car        |

Quel est le problème avec cette image? N'utilisateur 55 acheter deux barres de chocolat, ou une barre de chocolat et une pâte dentifrice? Ce type d'ambiguïté peuvent conduire à beaucoup d'efforts pour conserver les données de synchronisation, ce qui serait inutile si nous avons juste gardé l'une des clés étrangères. En fait, pourquoi ne pas abandonner le name colonne au total, depuis il est sous-entendu par la relation.

Bien sûr, on pourrait résoudre ce par la mise en œuvre d'un composite de clé étrangère, par la mise en PRIMARY KEY(i_id,name) pour la items table (ou de la définition d'un extra UNIQUE(i_id,name) indice, il n'a pas vraiment d'importance) et de définir ensuite un FOREIGN KEY(i_id,name) REFERENCES items(i_id,name). De cette façon, seulement (i_id,nom) les couples qui existent dans le items tableau serait valable pour user_purchases. Outre le fait que vous auriez encore un clé étrangère, cette approche est totalement inutile, à condition que le i_id colonne est déjà suffisant pour identifier un élément (ne peut pas en dire de même pour le name colonne...).

Cependant, il n'y a pas de règle contre l'utilisation de plusieurs clés étrangères de la table. En fait, il existe des circonstances de la demande d'une telle approche. Considérons un person(id,name) table et un parent(person,father,mother), avec les données suivantes:

 person             parent
| id  name    |    | person  father  mother |
| 14  John    |    |   21      14      59   |
| 43  Jane    |    |   14      76      43   |
| 21  Mike    |
| 76  Frank   |
| 59  Mary    |

Évidemment, tous les trois colonnes de la parent tableau sont des clés étrangères person. Pas la même relation, si, mais pour trois différents: Depuis les parents de la personne sont des personnes trop, les deux colonnes correspondantes doivent faire référence à la même table person. Notez, cependant, que les trois champs non seulement peut mais aussi ont pour consulter les différents persons dans la même parent ligne, puisque personne n'est son propre parent et la personne du père, c'est sa mère.

OriginalL'auteur geomagas

Au lieu de lire tant de liens, juste essayer de mettre en œuvre ce projet simple. Je suis juste en expliquant comment on va utiliser les tableaux ci-dessus.

Supposons que vous 3 utilisateurs en user table et 5 éléments dans items table.

user table

id  |  username |  password 
 1      abc         123
 2      def         456
 3      qwe         987 

items table

i_id  |  name   |  price 
 1      item 1    6
 2      item 2    8
 3      item 3    11 
 4      item 4    3
 5      item 5    14  

votre user_purchase table ressembler à ceci

CREATE TABLE user_purchase(
i_id INT(11) not NULL,
id INT(11) not NULL,
La CLÉ ÉTRANGÈRE (i_id) de référence à des éléments(i_id),
FOREIGN KEY (id) les RÉFÉRENCES de l'utilisateur(id)
);

Il n'y a pas besoin de nom d'élément nouveau dans ce tableau. J'ai donc supprimé.

i_id |  id  
 1      1      
 1      2
 2      2      
 3      3      

Dans le tableau ci-dessus, nous allons obtenir, l'utilisateur 1 a acheté l'article 1, utilisateur 2 a acheté l'article 1,article 2, et l'utilisateur 3 a acheté la rubrique 3.

C'est comment la normalisation des œuvres. Vous pouvez utiliser MySQL JOINDRE pour obtenir le nom d'utilisateur et les détails de l'élément

SELECT B.user_name,C.name AS item_name,C.price
FROM user_purchase A 
JOIN user B ON A.id = B.id
JOIN items C ON A.i_id = C.i_id

Ici est la clef étrangère utiliser pour joindre

A.id = B.id
A.i_id = C.i_id

OriginalL'auteur Shafeeque

Simplement en regardant la normalisation/dénormalisation point:

La normalisation est un processus d'essayer de supprimer les redondances dans votre base de données dans votre exemple, le name champ dans user_purchase est redondant - je peux savoir le nom de l'élément en regardant dans le items table à l'aide de i_id.

Donc, si nous devions chercher à normaliser user_purchase, nous aurions probablement supprimer la name champ et l'utilisation d'un JOIN les récupérer quand nous en avions besoin. Ce serait, bien sûr, signifie aussi nous n'avons pas besoin de la deuxième FOREIGN KEY référence à items.

De-la normalisation est fondamentalement va à l'opposé - l'ajout de redondance est en général faite pour des raisons de performances.

Cependant, dans votre exemple, vous pourriez aussi envisager de normalisation pour des raisons d'affaires. Par exemple, vous pourriez décider qu'il est important de stocker le nom du produit tel qu'il était lors de l'achat (plutôt que de ce qu'on l'appelle maintenant) - juste au cas où vous avez besoin pour être en mesure de ré-imprimer une facture par exemple. Cependant, même dans ce cas, vous ne voulez pas le FOREIGN KEY retour à items (comme il le ferait "pause" si le produit a été re-nommé).

OriginalL'auteur Clart Tent