Je ne suis pas très spécialiste de la base de donnée. Que sont les clés étrangères et à quoi servent elles ?
Ce sont des "propriétés" que l'on applique à un ou plusieurs champs d'une table pour la lier à une autre table. Un exemple valant mieux qu'un long discours :
table article contenant un champ "category_id"
table category contenant un champ "id"
la table article doit avoir une clé étrangère qui fait pointer son champ category_id vers category.id.
A quoi ça sert ? A assurer l'intégrité de ta base. A aucune moment elle ne doit permettre d'insérer un article qui n'a pas de catégorie. De même si tu supprimes une catégorie, il ne doit plus y avoir d'orphelins (ie des articles sans catégorie).
Sinon j'aurais une question à propos de inodb et des jointures : est ce qu'il le permet ?
(je n'utilise pas InnoDB) A mon avis, ce n'est pas une question de format de fichier stockage, mais de possibilité du SGBD (MySQL en l'occurence). Et MySQL gère parfaitement les jointures (encore heureux).
Avoir une table spéciale pour les jointures ne va être conceptuellement utile (je parle pas en terme d'optimisations etc.) que lorsqu'un article pourra appartenir à plusieurs catégories (pour reprendre l'exemple précédent). Plutôt que d'avoir article.category_id, tu aura une table article_category avec 2 champs : article_id et category_id (avec doublons autorisés pour chaque champ, mais pas pour un couple donnée).
[^] # Re: innodb
Posté par Pierrick Le Gall . En réponse au journal innodb. Évalué à 1.
Ce sont des "propriétés" que l'on applique à un ou plusieurs champs d'une table pour la lier à une autre table. Un exemple valant mieux qu'un long discours :
la table article doit avoir une clé étrangère qui fait pointer son champ category_id vers category.id.
A quoi ça sert ? A assurer l'intégrité de ta base. A aucune moment elle ne doit permettre d'insérer un article qui n'a pas de catégorie. De même si tu supprimes une catégorie, il ne doit plus y avoir d'orphelins (ie des articles sans catégorie).
(je n'utilise pas InnoDB) A mon avis, ce n'est pas une question de format de fichier stockage, mais de possibilité du SGBD (MySQL en l'occurence). Et MySQL gère parfaitement les jointures (encore heureux).
Avoir une table spéciale pour les jointures ne va être conceptuellement utile (je parle pas en terme d'optimisations etc.) que lorsqu'un article pourra appartenir à plusieurs catégories (pour reprendre l'exemple précédent). Plutôt que d'avoir article.category_id, tu aura une table article_category avec 2 champs : article_id et category_id (avec doublons autorisés pour chaque champ, mais pas pour un couple donnée).