Si on va par là, un article de blog et un commentaire ne sont pas fondamentalement différents non plus. Ils sont tous les deux composés de texte et/ou d'image, ils ont tous les deux un auteur, et ils sont tous les deux liés à une URL. La seule différence (a priori, mais ton application peut être plus complexe), c'est que l'article est autonome, alors que le commentaire est rattaché à un article. Il y a plusieurs façons de modéliser ça. Quelques exemples :
si on estime que malgré leur ressemblance technique, un article et un commentaire sont vraiment fonctionnellement très différents, on peut utiliser deux tables.
si la différence n'est pas si marquée, on peut avoir une colonne indiquant si le commentaire es rattaché un commentaire parent (cad l'article). Pour l'application, du point de vue fonctionnel, si le commentaire n'a pas de parent, c'est que c'est un article. S'il a un parent, c'est un commentaire.
on peut même simplifier encore en remarquant que dans une succession de commentaires rattachés à une même URL, l'article, c'est le premier commentaire dans l'ordre chronologique. On peut avoir une structure en DB très simple pour modéliser tant un article qu'un commentaire (auteur, date, contenu, url), et laisser l'application se débrouiller pour trier entre article et commentaire.
...
Ta question sur le nom "user_blog_articles_comments" est très pertinente. En effet, si tu commences à nommer tes tables avec les noms des colonnes sur lesquelles portent des contraintes de clef étrangère, t'es mal barré. Dans tous les cas, je pense que ça vaudrait le coup que tu modélises ta DB (à un niveau d'abstraction au dessus de la technique) avant de commencer à définir la structure technique des tables de la DB. Je crois qu'il faut aussi viser le modèle de DB le plus simple possible qui puisse répondre au besoin. C'est beaaauuuuuucoup plus simple de changer du code que de changer la structure d'une DB (pour de la DB relationnelle).
Perso, j'aime bien le modèle entité/association (google est ton ami). Il m'a souvent aidé à comprendre ce que j'essayais de faire, et si la modélisation est bien faite (et la première itération n'est jamais la bonne), la traduction en modèle relationnel est quasi automatique. (Regarde aussi du côté des formes normales)
[^] # Re: logique à 2 niveaux
Posté par gaaaaaAab . En réponse au message Question sur le nommage des tables. Évalué à 2.
Si on va par là, un article de blog et un commentaire ne sont pas fondamentalement différents non plus. Ils sont tous les deux composés de texte et/ou d'image, ils ont tous les deux un auteur, et ils sont tous les deux liés à une URL. La seule différence (a priori, mais ton application peut être plus complexe), c'est que l'article est autonome, alors que le commentaire est rattaché à un article. Il y a plusieurs façons de modéliser ça. Quelques exemples :
Ta question sur le nom "user_blog_articles_comments" est très pertinente. En effet, si tu commences à nommer tes tables avec les noms des colonnes sur lesquelles portent des contraintes de clef étrangère, t'es mal barré. Dans tous les cas, je pense que ça vaudrait le coup que tu modélises ta DB (à un niveau d'abstraction au dessus de la technique) avant de commencer à définir la structure technique des tables de la DB. Je crois qu'il faut aussi viser le modèle de DB le plus simple possible qui puisse répondre au besoin. C'est beaaauuuuuucoup plus simple de changer du code que de changer la structure d'une DB (pour de la DB relationnelle).
Perso, j'aime bien le modèle entité/association (google est ton ami). Il m'a souvent aidé à comprendre ce que j'essayais de faire, et si la modélisation est bien faite (et la première itération n'est jamais la bonne), la traduction en modèle relationnel est quasi automatique. (Regarde aussi du côté des formes normales)