Bonsouère bonsouère

Voilà, j'ai construit une base de données via un fichier YAML, et j'aimerais savoir si mon schéma relationnel est bon.
J'ai obtenu ce schéma en faisant un import dans le logiciel MysqlWorkbench du fichier SQL exporté par phpmyadmin.

J'ai voulu modéliser ceci :

• Un membre peut créer 0 à n jeu(x)
• Un membre peut créer 0 à n fiche(s)
• Un membre peut créer 0 à n news
• Un jeu et une fiche possède un topic (sorte de thème)
• Une news possède 0 à n commentaire(s)
• Un membre peut créer une news
• Un commentaire est écrit par un membre

Bref, le voici :








Bref, est-ce que vous voyez des erreurs de conception ou bien tout roule nickel ?

Personnellement, mais je ne suis pas sûr (disons que les SGBD et moi... ) ; j'ai l'impression que la relation entre membre et commentaire n'est pas présente.
En soi ce n'est pas vraiment un mal (mais au niveau de l'aspect logique de la BDD, cay mal) ; car il suffit de vérifier que le membre existe bien via le code (mais pas pratique, j'en conviens).

Il y a aussi une question que je me pose :

Si un membre poste une news, et qu'ensuite il est supprimé de la BDD (demande de suppression de compte par exemple) ; que ce passe-t-il niveau relationnel ?
Est-ce que je me plante complet si j'affirme que "tant qu'il n'y a pas un "ON_DELETE: CASCADE", la news (et tout le reste posté par le membre) restera dans la BDD ?

Merci d'avance pour vos avis et/ou explications

Bon ...

J'ai du mal à lire ton modèle pour plusieurs raisons :
Tu mets id partout, quand tu n'as pas le nom de la table, on ne voit pas bien ce que cela représente.
J'essaie de traduire ton truc en schéma relationnel

MEMBRE(id_membre)
TOPIC (id_topic)
JEU(id_jeu, #id_membre, #id_topic)
NEWS(id_news, #id_membre)

Bon, cette partie là c'est clair

Maintenant ta table fiche je vois pas trop ce que c'est ??
FICHE(id_fiche, #id_membre, #id_topic) c'est très curieux, 90% chance que ce soit pas adapté !!

Ensuite
COMMENTAIRE(id_comment, #id_membre) là tu ajoutes #id_news et c'est bon, tu zappes ta table jonction.

****************************

Si tu utilises Mysql, utilise Innodb, sinon pas d'intégrité référentielle (alors ton on delete cascade tu peux l'oublier)
Par contre, c'est toi qui décide si ta news est supprimée avec le membre il suffit d'indiquer NOT NULL sur la colonne id_membre qui est clef étrangère pour que ce soit impossible de supprimer un membre qui a écrit une news. Si tu mets NULL sur la colonne, une news peut exister sans membre.
Voilà !

Merci pour ta réponse rapide

en fait les id qui sont partout sont dûs au fait que dans le fichier YAML, je ne les précisent pas et ils sont mis par défaut (comme ça pas d'erreur possible quand au nommage (c'est toujours 'id')). Disons dans un premier temps que ça m'a aidé à comprendre comment créer les relations en YAML).
Mea culpa, j'aurais du préciser que les clés où il y a un "f" devant correspondent au f-keys!

Sinon j'utilise bien InnoDB par défaut (mais pas le ON-DELETE CASCADE )

Merci pour les précisions sur [not-]null et les f-keys ; je fais ça de suite

Par contre ya un truc que je ne comprends plus. u_u
Tu me précises une façon de faire pour kniacker la table de jonction..je comprends tout à fait. Mais du coup ça remet en cause ma vision de l'utilité des tables de jonctions.. (ou des relations many-to-many).
Je pensais ça pourtant vachement adapté à mon cas

Aurais-tu par hasard un exemple de situation où l'on ne peut pas faire autrement qu'utiliser une relation many-to-many ? (Donc où ta façon de faire ne s'appliquerait pas).

C'est juste pour bien comprendre l'utilité des tables de jonctions

Sinon, quand tu dis :

Citation : fa_bio

FICHE(id_fiche, #id_membre, #id_topic) c'est très curieux, 90% chance que ce soit pas adapté !!

Que veux-tu dire ? Vaut-il mieux concevoir une table pour les topics des jeux et une table pour les topics des fiches ?

Merci d'avance pour tes réponses

B'soir,

Pour fiche, en fait, je n'ai pas bien compris à quoi cela correspond. Le risque, c'est que ce soit une édition et non un objet de ton domaine, dans ce cas c'est le fruit d'une requête, voire une vue !!

Citation : captaingigicoin

Aurais-tu par hasard un exemple de situation où l'on ne peut pas faire autrement qu'utiliser une relation many-to-many ? (Donc où ta façon de faire ne s'appliquerait pas).

A priori, cela pourrait servir si un même commentaire pouvait concerner plusieurs news (cas plutôt pas réaliste) ... En fait, c'est quand tu as une contrainte du style "une ligne de facture concerne un produit mais on ne veut pas qu'une autre ligne de la même facture concerne le même produit". Je sais pas si je suis clair !

Plop!

Merci pour ta réponse

Non, en fait fiche représente une fiche techniques (avec un titre, sous-titre, content, id_author...etc

-> Même comportement qu'une news quoi.

D'ailleurs, je me demande, y'a t'il une possibilité de mettre en place une sorte d'héritage dans une BDD relationnelle ? (juste pour savoir hein)

Bon, donc sinon est-ce le plus simple que je garde la relation many-to_many ou bien que je fasse selon ta méthode (niacker la table de jonction) ?

Non parce qu'ayant à présent une vision globalement orienté objet (suite à de nombreux cours), je dirais que chaque entité doit faire son boulot (et j'aurais donc tendance à préférer la table de jonction).

Désolé, mais 3 jours de TAF un peu intense.
Sur le principe objet de la responsabilité, pas de problème, c'est un des principes essentiels de l'objet.
Maintenant, cela ne s'applique pas à ta table jonction :
1 - Car n'est pas un objet du réel mais un moyen technique
2 - L'idée est d'avoir un couplage faible, il est encore plus fort avec la jonction.
3 - Cela ne répond pas à tes règles de gestion.

En gros, quand tu parles responsabilité tu te poses la question du couplage. Plus un objet dépend d'un autre, plus le couplage est fort et moins c'est bon conceptuellement (cohésion de l'objet - tu peux relire Meyer à ce sujet).

Voilà, maintenant tu peux avoir une conception pas tout à fait dans les règles de l'art et une appli en prod. qui tient depuis des années !