Version imprimable
Bonjour,
Je cherche à faire un système de commentaires. Les commentaires pourront être fait soit sur des personnes, soit sur des articles et soit sur des photos.
Je me demande si je fais une seule table avec les clé etrangeres vers photos, personnes et articles. Ou bien est-ce qu'il est préferable de faire une table commentaires photos, une autre commentaires articles...
Qu'en pensez vous ?
Merci
Salut , tous dépend de votre modélisation !!
Comment ils sont stockés les personnes , les photos et autres ?
de là vous pouvez faire un choix.
Bonjour,
Toutes les tables sont séparées et liées par des clé etrangeres genre pour photos:
idphoto, iduser, nom, largeur...
Salut
A mon sens il ne devrait pas avoir beaucoup de choix.Citation:
Je me demande si je fais une seule table avec les clé etrangeres vers photos, personnes et articles. Ou bien est-ce qu'il est préferable de faire une table commentaires photos, une autre commentaires articles...
Tout est une question de cardinalités (ou relation) entre chacun d'eux, entre chacune des données.
- SI pour 1 photo (ou chaque photo) tu souhaites qu'il y ait 1 seul et unique commentaire (1 par photo donc), alors le champ "commentaire" pourra être rajouté à la table "photos".
Les cardinalités entre photo et commentaires sont : 1-1
- Par contre, SI pour 1 photo (ou chaque photo) tu souhaites qu'il y ait plusieurs commentaires possibles, alors il faudra créer une table genre "commentaire_photo" pour cela.
Les cardinalités entre photo et commentaires sont : 1-n
Faut définir les cardinalités pour ces autres tables, c'est cela qui détermine s'il faut ou pas rajouter une table.
Pour les commentaire d'articles à mon sens il y a de fortes chance qu'un article pourra avoir plusieurs commentaire, donc des cardinalités : 1-n
Idem pour les commentaires entre user.
Tout ça c'est à toi de voir ;)
Les cardinalités seront de 1 a n, ce que je me demande c'est si je fais une seule table commentaires ou faire une table commentaires_photos, commentaires_articles...
Pour ma part, j'aurais tendance à essayer d'avoir une table par type, de sorte à pouvoir mettre en place une clé étrangère de chaque table commentaire vers chaque source de contenu.
mais si j'ai qu'une seule table avec 3 clés etrangeres ? soit je mets l'id soit je mets 0 par exemple, non ?
L'idée est vraiment d'avoir une seule foreign key qui lie l'id de la ressource dans les deux tables.
Si tu mélanges tout, il y aura forcément un moment où tu auras des risques de corruption des données.
tu peux plus détailler ton point de vue cela m'interresse stp
C'est justement en définissant son besoin, donc les cardinalités, qui débouche sur le modèle de donnée (table, champs, etc ...).Citation:
Les cardinalités seront de 1 a n, ce que je me demande c'est si je fais une seule table commentaires ou faire une table commentaires_photos, commentaires_articles...
Donc si tu dis que les cardinalités sont 1:n, il n'y plus de question à se poser, il me semble l'avoir déjà expliqué.
Re - exemple.
On dit que pour 1 article on va avoir plusieurs commentaires (card. -> 1:n) :
table : article (pour tous les articles) ->
champs : id (clé primaire)
table : article_commentaire (pour les commentaires des chaque article)
champ : id (clé primaire) | id_article (clé étrangère)
C'est aussi simple que ça.
Maintenant, quand tu te pose la question s'il faudrait une table "commentaire" seule, donc autre que article_commentaire, on peu supposer que tu souhaiterais un fonctionnement différent.
Mais c'est purement hypothétique, tu ne l'a pas exprimer jusqu'à lors.
Pour définir des cardinalités (donc comment structurer ces tables par rapport aux données), il faut avoir les idées claires pour bien exprimer son besoin.
Je m'explique.
Prenons cette table "article_commentaire" justement, donc cardinalité : 1:n
Donc actuellement un article peu être lié à plusieurs commentaires.
Cependant un commentaire ne peut être lié qu'à 1 seul article (d'où le 1:n).
Admettons maintenant que ton besoin change, et que tu l'exprime de la façon suivante :
Un même commentaire pourra être exploité (ou lié) par plusieurs articles.
Et bien les cardinalités vont automatiquement changés pour ceci : n:n
Ce n'est plus la même chose.
Et bien c'est dans ce cas là où il faudra créer (ou rajouter) une table "commentaire" pour y mettre juste les commentaires, et conserver la table "article_commentaire" pour faire les liaisons entre les articles et commentaires.
Donc 3 tables : article, commentaire, commentaire_article
Mais admettons que ton besoin évolue encore pour exprimer la chose suivante :
Un même commentaire pourra être exploité par un article, mais aussi par une photo, voir aussi par les personnes.
Dans ce cas là, on obtient la même chose que précédemment, c'est à dire qu'il faudrait avoir 1 table "commentaire" et lier cette table avec les divers autres tables, genre article_commentaire, photo_commentaire, user_commentaire.
On a cette cardinalité là entre commentaire et les autres tables -> 1:n
Bref.
Là où je veux en venir, c'est qu'il ne faut pas te focaliser sur les tables, le nombre de table ou encore les clés étrangères, c'est pas la bonne démarche.
C'est avant tout de bien exprimer son besoin, c'est ce que j'ai fait avec mes exemples (ce sont juste des exemples).
C'est ça qui va faire qu'on visualisera les cardinalités, et c'est ces cardinalités là qui vont dicter les tables à créer.
Les clés étrangères vont se dessiner tout naturellement aussi.
Toujours est il que les clés étrangères ne se mettent pas au pif, au feeling, ou autre façon plus ou moins hasardeuse.
Par ailleurs, faire autrement ce qu'exprime son besoin (ou les cardinalités), c'est aller au-devant de problèmes, et en général c'est l'application qui va trinquer (le code Php entre autre, le code SQL bien souvent aussi).
Donc exprime clairement ce que tu veux obtenir, c'est ça la base ;)
Et il faut le faire pour chaque donnée, donc une par une.
Disons que certaines sont évidentes, mais attention au piège parfois.
Tout ça sauf erreur ;)
J'hésitais mais je pense que je vais suivre le modèle que tu as développé :Citation:
Dans ce cas là, on obtient la même chose que précédemment, c'est à dire qu'il faudrait avoir 1 table "commentaire" et lier cette table avec les divers autres tables, genre article_commentaire, photo_commentaire, user_commentaire.
On a cette cardinalité là entre commentaire et les autres tables -> 1:n
Comme disait un certain humoriste : C'est vous qui voyez :DCitation:
J'hésitais mais je pense que je vais suivre le modèle que tu as développé