Page 1 sur 1
Conseil pr tables MySQL
Posté : 14 mai 2005, 17:27
par thepioche
Bonjour,
j'ai un p'tit renseignement à vous demander, donc en faite j'ai un site sur le rock, où je présente, des groupes, et donc pour chaque groupes je met les albums CD, DVD, EP... etc ...
Bon bref, il faut les enregistrer dans ma base de donnée, et je voudrait savoir s'il ai mieu de faire une table pour chaques groupes, ou une table qui regrouperait tout les enregistrements d'albums de tout les groupes, (ça montrait déjà a 200 pour seulement 25groupes!) donc voila c'est pour savoir en gros si le mieu est plusieur table pour mieu classé, ou une table avec tout dedans...
Et puis en plus, chaques groupe me fait créer 2tables, une pour les labums une autre pr les liens...
Quelles est la meilleure solution?
table relationnel
Posté : 14 mai 2005, 17:52
par johan
Salut
voila comment je ferais
une table "groupe" avec champs id_groupe (PK), nom ....
une table "album" avec champs id_album (PK), nom,..., id_groupe (FK)
et si tu veux aussi enregistrer s ils ont des dvds, je ferais un troisieme table DVD dans le meme principe. La multiplicté des tables n est pas une probleme, et se sera plus facile pour tes recherches ensuite.
De tout facon, a partir du moment ou un groupe peut avoir un ou plusieurs albums, un shema UML (ou merise) te dirait de faire deux tables séparées.
PK: Primary Key
FK: Foreign Key
En esperant avoir repondu
Posté : 14 mai 2005, 18:15
par albat
Johan te donne une bon début, mais perfectible. =D>
Pourquoi faire une table CD et une table DVD qui seront redondantes ?
Mieux vaut construire une table PRODUIT, plus générique...
Table GROUPE
- groupe_id : entier auto-incrément (CP : clé primaire)
- groupe_nom : chaine
- etc.
Table PRODUIT
- produit_id : entier auto-incrément (clé primaire)
- groupe_id : entier (clé étrangère)
- produit_type : entier/enum (CD, DVD, K7, DAT, VHS, livre,...)
- etc.
table relationnel suite
Posté : 14 mai 2005, 18:24
par Johan
C est vrai,
en fait dans mon idée initiale les champs de la table album et ceux de la table dvd seraient différents. En y reflechissant, ils se pourraient que ce soit quasiment les memes. Donc je rejoins la proposition d albat
Posté : 14 mai 2005, 21:34
par daoud
On pourrait peut-être même faire une table type ou catégorie qui serait reliée à produit ?
a+
daoud
Posté : 14 mai 2005, 22:45
par albat
Tout à fait.
C'est à Thepioche d'y réfléchir en analysant l'appli qu'il veut développer.
Mais c'est effectivement une possibilité à ne pas négliger,
si la liste des catégories est amenée à évoluer (nouveaux types de supports)
Posté : 15 mai 2005, 19:17
par thepioche
merci pour vos réponses!
oui je vais suivre se que vous me conseiller de faire... bon je comprend pas tout (clé étrangère notamment), mais avec de la documentation plus spécifiques sur PHP je pense que j'y arriverai! Merci beaucoup à vous trois!
Au revoir!
Posté : 15 mai 2005, 19:21
par albat
Chaque table doit contenir une clé primaire qui est l'identifiant unique de chaque enregistrement (= ligne).
En général, on crée un champ numérique entier auto-incrémenté.
Posté : 15 mai 2005, 19:35
par rami
merci pour vos réponses!
oui je vais suivre se que vous me conseiller de faire... bon je comprend pas tout (clé étrangère notamment), mais avec de la documentation plus spécifiques sur PHP je pense que j'y arriverai! Merci beaucoup à vous trois!
Au revoir!
La clé étrangère dans une table permet de faire le lien avec une autre table. En effet, cette clé étrnagère correspond à une clé primaire de la table avec laquelle elle est en relation. C'est un des principes fondamentaux des SGBD
Relationnel.
Fais des recherches sur Merise sur google. Tu trouveras des tas de tutoriaux pour apprendre
