En effet l'id ne sert à rien (une vieille habitude de CakePHP), merci d'avoir corrigé la coquille
----- Mail original ----- | Bonjour, | Petite incruste dans la conversation :-) | Le 11 mars 2014 09:27, < [email protected] > a écrit : | | Du point de vue base de données pure, logiquement on fait une table | | de jointure type "auteurs_ouvrages" (avec l'hypothèse qu'on a les | | tables "auteurs" et "ouvrages") dans laquelle chaque ligne comporte | | : | | | - id | | | - ouvrage_id | | | - auteur_id | | Je ne suis pas d'accord, id ne sert à rien, les champs auto généré ne | doivent être utilisé que lorsque cela est utile, or là ils ne le | sont pas car les deux Sophie n'ont pas le même id_auteur. Qui plus | est en mettant cette colonne la (en clé primaire composé de ce seul | attribut) on peut avoir plusieurs fois le même auteur sur le même | bouquin, ce qui me parait un peu déconcertant tout de même. Et en | plus c'est pas en 2NF avec l'attribut id. Donc selon moi : | - ouvrage_id* | - auteur_id* | | Ceci permet la relation 1 à N de auteur à ouvrage. | | | Dans cette table, l'id s'auto-incrémente et on aura éventuellement | | plusieurs lignes avec le même ouvrage mais différents auteurs, se | | qui permet de retrouver tous les auteurs d'un ouvrage ou tous les | | ouvrages auquel un auteur a participé ... | | Dans tout les cas tu peux associer les auteurs à leurs bouquins ou | les livres à leurs auteurs, je ne vois pas en quoi la table de | relation rendrait cette tache plus complexe. Suffit simplement de | joindre les trois tables et de selectionner via soit l'id de | l'auteur, soit l'id de l'ouvrage en fonction du type de recherche. | | ----- Mail original ----- | | | | Le 10/03/2014 18:08, Claude FRICARD a écrit : | | | | | | | | Bonjour, | | | | | | | | Et si, avec ta méthode, tu fais une recherche sur l'ensemble des | | | | ouvrages écrits par Pierre Souvestre, qu'il les ait écrits seul | | | ou | | | | qu'il | | | | ait participé à l'écriture avec un ou plusieurs autres auteurs, | | | | est-ce | | | | que ta méthode te permettra de sortir cette information en une | | | seule | | | | opération et avec la certitude que le Souvestre apparaissant | | | comme | | | | co-auteur des romans de la série FANTOMAS est le même que le | | | Pierre | | | | SOUVESTRE auteur en 1907 de "Histoire de l'Automobile" ? | | | | | | | | Prenons un exemple plus proche de nous ; imaginons que tu doives | | | | entrer | | | | dans ta table des ouvrage, un livre paru en 2012 aux éditions | | | | Eyrolles | | | | et intitulé "De OpenOffice.org à LibreOffice 3.5" ; cette fois, | | | ils | | | | s'y | | | | sont mis à 5 pour l'écrire, il y avait Sophie Gautier, Gilles | | | | Bignebat, | | | | Christian Hardy et Michel Pinquier et l'éditeur mentionne la | | | | contribution de Jean-François Nifenecker ; comment tu renseignes | | | les | | | | auteurs dans ta table T_Auteurs ? Si j'ai bien compris ce que tu | | | as | | | | écrit tu va mettre Gauthier&Bignebat&Hardy&Pinquier&Nifenecker. | | | | | | | | Maintenant, tu dois aussi entrer un autre ouvrage, paru en Mars | | | 2009 | | | | et | | | | intitulé "OpenOffice.org 3 efficace" écrit par Sophie Gauthier, | | | | Laurent | | | | Godard et Christian Hardy ; cette fois, si j'ai bien compris, tu | | | vas | | | | créer un auteur appelé Gautier&Godard&Hardy ? | | | | | | | | Le problème, c'est que Sophie Gauthier elle écrit souvent à | | | plusieurs | | | | mains et pas toujours avec les mêmes mains ; ainsi, on lui trouve | | | une | | | | collaboration avec un autre duo, composé de Christian Hardy et de | | | | Frédéric Labbé , puis un autre composé de Michel Pinquier et de | | | | Christian Hardy et avec un trio composé de Christian Hardy, de | | | | Fédéric | | | | Labbé et de Michel Pinquier. | | | | | | | | Et en plus, il lui est arrivé des commettre des ouvrages toute | | | seule. | | | | | | | | Du coup, comment se comporte ta table à son égard ? Tu vas créer | | | | autant | | | | d'auteurs différents qu'il y aura de compositions différentes ? | | | Mais | | | | si | | | | un jour tu veux identifier tous les ouvrages dont elle est | | | l'auteur | | | | ou | | | | le co-auteur, est-ce que ta table le permettra en une seule | | | requête | | | | ou | | | | est-ce que tu devras interroger ta table autant de fois qu'il | | | existe | | | | de | | | | formes différentes sous laquelle elle apparaît parmi les auteurs | | | ? | | | Et | | | | que se passe-t-il s'il existe une autre Sophie Gauthier qui se | | | met | | | à | | | | écrire des ouvrages sur des sujets totalement différents (ou pas | | | | d'ailleurs) ? | | | | | | | | De mon point de vue, une même personne ne doit apparaître qu'une | | | | seule | | | | fois dans la table Auteurs, de sorte que l'on ne puisse jamais | | | avoir | | | | à | | | | se demander, par exemple, si le "Gauthier" qui apparaît au milieu | | | de | | | | "Gauthier&Bignebat&Hardy&Pinquier&Nifenecker" comme auteur de "De | | | | OpenOffice.org à LibreOffice 3.5" est la Sophie Gauthier de | | | | "OpenOffice.org 2 efficace" ou si c'est une autre personne. | | | | | | | | Sur ce principe : | | | | - un ouvrage n'apparaît qu'une fois dans la table des ouvrages ; | | | | - un auteur unique n'apparaît qu'une fois dans la table des | | | auteurs | | | ; | | | | - la relation entre les uns et les autres apparaît dans une | | | troisième | | | | table, l'id_ouvrage d'un ouvrage comptant 5 auteur apparaissant | | | alors | | | | 5 | | | | fois dans cette table avec, à chaque ligne, une id_auteur | | | différente. | | | | | | | | De cette façon, la Sophie Gauthjier qui a écrit ou co-écrit les | | | | ouvrages | | | | évoqués ci-dessus se verra créditée de tous ses ouvrages en une | | | seule | | | | fois lorsqu'on interrogera la base de données et s'il y a une | | | autre | | | | Sophie Gauthier, plutôt spécialisée dans les livres de cuisine | | | mais | | | | qui | | | | a commis elle aussi un ouvrage sur l'informatique, chaque Sophie | | | | Gauthier ne sera créditée QUE de ses ouvrages mais de TOUS ses | | | | ouvrages. | | | | | | | | Donc oui, c'est probablement un peu plus fastidieux à mettre en | | | | oeuvre ; | | | | mais à mon avis, ce sera une base beaucoup plus facile à | | | exploiter, | | | à | | | | maintenir et même à faire évoluer au fil des besoins. | | | | | | | | Pour ma part, je retiendrais la solution préconisée par | | | Jean-François | | | | Nifenecker. | | | | | | | | A+ | | | | | | | -- | | | M. Cyrille GROSDEMANGE | | | Service Informatique et Réseaux | | | Mairie d'Audincourt | | | ---- | | | Pensez à la planète : êtes-vous certain d'avoir besoin d'imprimer | | ce | | mail ? | | | Seuls des formats ouverts peuvent assurer la pérennité de vos | | documents. | | | -- | | | Envoyez un mail à [email protected] pour savoir | | comment vous désinscrire | | | Les archives de la liste sont disponibles à | | http://listarchives.libreoffice.org/fr/users/ | | | Tous les messages envoyés sur cette liste seront archivés | | publiquement et ne pourront pas être supprimés | | -- | Arnaud Versini -- M. Cyrille GROSDEMANGE Service Informatique et Réseaux Mairie d'Audincourt ---- Pensez à la planète : êtes-vous certain d'avoir besoin d'imprimer ce mail ? Seuls des formats ouverts peuvent assurer la pérennité de vos documents. -- Envoyez un mail à [email protected] pour savoir comment vous désinscrire Les archives de la liste sont disponibles à http://listarchives.libreoffice.org/fr/users/ Tous les messages envoyés sur cette liste seront archivés publiquement et ne pourront pas être supprimés
