Quel schéma de Table(s) pour système de commentaires

[guy2004]

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

[redoran]

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.

[guy2004]

Bonjour,
Toutes les tables sont séparées et liées par des clé etrangeres genre pour photos:
idphoto, iduser, nom, largeur...

[RunCodePhp]

Salut

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...

A mon sens il ne devrait pas avoir beaucoup de choix.
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

[guy2004]

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...

[Théocrite]

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.

[guy2004]

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 ?

[Théocrite]

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.

[guy2004]

tu peux plus détailler ton point de vue cela m'interresse stp

[RunCodePhp]

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...

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 ...).

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

[guy2004]

J'hésitais mais je pense que je vais suivre le modèle que tu as développé :

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

[RunCodePhp]

J'hésitais mais je pense que je vais suivre le modèle que tu as développé

Comme disait un certain humoriste : C'est vous qui voyez