Le problème "des livres / des auteurs"
Le problème "des livres / des auteurs" | Page d'accueil de L'atelier LAMP |
Dans votre base MySQL, vous voulez séparer les livres et les auteurs de ces livres : les livres dans une table et les auteurs dans une autre.
Pour la relation que vous voulez établir entre les livres et les auteurs, vous avez en gros le choix entre les 3 possiblités suivantes (dans l'ordre croissant de difficulté d'implémentation) :
Même si vous êtes conscient qu'il serait plus réaliste qu'un livre puisse être associé à plusieurs auteurs, vous faites le choix délibéré de ne lui associer qu'un auteur.
N peut valoir 2, 3, 4 ou 5 : sa valeur doit être choisie judicieusement (après mûre réflexion) avant de commencer à développer l'application. Augmenter sa valeur plus tard impliquerait des modifications de la structure de la base, des requêtes SQL, des formulaires HTML et des scripts PHP qui constituent votre application. La valeur de N doit donc être choisie une bonne fois pour toutes et être de préférence inférieure à 4 ou 5. Au-delà, il vaut mieux opter pour la solution C. Si l'on n'est pas sûr de ne pas être amené un jour à augmenter sa valeur, il vaut mieux opter d'emblée pour C.
Vous ne souhaitez pas imposer de limite à priori au nombre d'auteurs qui pourront être associés à un livre. Ce faisant il y aura un prix à payer : vous devrez créer une table supplémentaire (appelée table de liaison) pour enregistrer les relations entre les lignes de la table des livres et celles de la table auteurs. Les requêtes SQL que vous utiliserez dans vos scripts PHP seront donc plus compliquées à formuler !
Il est important de faire le bon choix dès le départ,
car, de ce choix va dépendre toute l'implémentation,
c'est-à-dire, le nombre et la structure des tables MySQL
ainsi que le code source des formulaires HTML et scripts PHP
qui vont permettre aux utilisateurs de votre application de consulter,
insérer, mettre-à-jour, etc ... les données
des tables.
Attention aux raisonnements rapides du genre :
Qui peut le plus peut le moins ... donc je choisis
la solution C !
car le prix élevé
de cette solution (en terme d'effort de développement)
ne doit pas être sous-estimé.
Dans tous les cas, la structure de la table auteurs sera la même :
CREATE TABLE `auteurs` (
`a_id` SMALLINT UNSIGNED AUTO_INCREMENT,
`nom` VARCHAR(255),
`prenom` VARCHAR(255),
PRIMARY KEY (`a_id`)
);
|
Il va de soit qu'un auteur présent dans la table auteurs peut être l'auteur de plusieurs livres de la table des livres. Si c'est le cas, cet auteur devra de toutes façons n'être enregistré qu'une seule fois dans la table auteurs.
Quelque soit le type de relation retenu, la table des livres aura au moins les colonnes suivantes :
N.B. : Pour simplifier on ne va garder que les colonnes l_id, titre et annee.
Mais la (les) colonne(s) concernant l' (les) auteur(s) dépendent du type de relation choisi :
On rajoute la colonne auteur qui servira à enregistrer l'identifiant de l'unique auteur du livre.
CREATE TABLE `A_livres` (
`l_id` SMALLINT UNSIGNED AUTO_INCREMENT,
`titre` VARCHAR(255),
`annee` SMALLINT UNSIGNED,
`auteur` SMALLINT UNSIGNED,
PRIMARY KEY (`l_id`)
);
|
On rajoute les colonnes auteur1, auteur2 et auteur3 qui serviront à enregistrer les identifiants des 3 auteurs du livre.
CREATE TABLE `B_livres` (
`l_id` SMALLINT UNSIGNED AUTO_INCREMENT,
`titre` VARCHAR(255),
`annee` SMALLINT UNSIGNED,
`auteur1` SMALLINT UNSIGNED,
`auteur2` SMALLINT UNSIGNED,
`auteur3` SMALLINT UNSIGNED,
PRIMARY KEY (`l_id`)
);
|
On ne rajoute aucune colonne mais on crée une table supplémentaire, qu'on va appeler C_livres2auteurs, et qui va servir à enregistrer les relations entre livres et auteurs.
CREATE TABLE `C_livres` (
`l_id` SMALLINT UNSIGNED AUTO_INCREMENT,
`titre` VARCHAR(255),
`annee` SMALLINT UNSIGNED,
PRIMARY KEY (`l_id`)
);
CREATE TABLE `C_livres2auteurs` (
`l_id` SMALLINT UNSIGNED NOT NULL,
`a_id` SMALLINT UNSIGNED NOT NULL,
UNIQUE KEY (`l_id`,`a_id`)
);
|
| Page d'accueil de Hervé Pagès | Contact : herve.pages@free.fr |