Salut,
je suis en train de bosser sur une base de données un peu complexe, qui utilise quasiment que des relations entre tables. Je voudrais donc savoir comment bien nommer les tables, histoire d'avoir de bonnes pratiques et de bien m'organiser.
Par exemple, dans ma table, un membre possède un profil et ce profil possède un avatar, cela donnerait comme tables :
- users
- user_profiles
- user_profile_avatars
Et si je dis qu'un membre possède un blog dont ce dernier possède des articles qui possèdent des commentaires, ça donne quoi ? user_blog_articles_comments ?
Je trouve que ça fait vraiment long surtout que ça peut devenir encore plus long.
A la place user_profile_avatars, n'est-il pas plus judicieux de choisir user_avatars, car dans tous les cas la relation final pointera toujours le membre en tant propriétaire ?
Merci pour votre lumière.
# Sur la bonne voie
Posté par cfx . Évalué à 1.
Ta notation à base de minuscules, underscores et mots au pluriel est ce qui est utilisé par la plupart des frameworks Web. Par exemple, dans Active Record (l'ORM principal de Ruby on Rails).
Quand aux noms à rallonge, à moins d'avoir une application complexe avec différents types de profils/avatars/commentaires/[…], normalement tu devrais pouvoir t'en sortir en utilisant uniquement l'élément principal comme nom. D'autant plus qu'on s'en fiche pas mal que l'avatar soit accessible depuis le profile, il s'agit avant tout de l'avatar de l'utilisateur. De même que les articles (d'ailleurs, pourquoi les lier au profile ?), ce sont les articles de l'utilisateur. Et les commentaires, ce sont ceux des articles.
[^] # Re: Sur la bonne voie
Posté par shingo (site web personnel) . Évalué à 1.
Justement, le problème de mon projet c'est que je ne peux pas utiliser une seule table. Par exemple, je voudrais permettre aux membres de poster des commentaires sur une photo, un album photo, un fil d'actualité, un article, une vidéo etc.
Pour les articles, non ces derniers son lié à un journal ou à un blog.
[^] # Re: Sur la bonne voie
Posté par cfx . Évalué à 1.
Ces différents commentaires sont ils structurellement différents ?
Si ce n'est pas le cas, tu devrais pouvoir tous les stocker dans une même table, modulo le fait de stocker le type de l'objet que tu commentes en plus de son id (ou bien d'utiliser des uuid pour toutes tes tables).
# logique à 2 niveaux
Posté par NeoX . Évalué à 2.
mon avis sur la question serait le suivant
2 niveaux :
- les pluriels
- les singuliers.
ca donne donc
users
user_pofiles
profile_champs
[^] # Re: logique à 2 niveaux
Posté par shingo (site web personnel) . Évalué à 1.
J'y ai pensé, mais que faire si demain je décide d'ajouter une table profile destiné à un autre objet.
Exemple, un "membre" peut avoir un "profil" et une "entreprise". Une "entreprise" peut aussi avoir une profil.
Donc soit je crée une table profile avec deux clés étrangères (pas top), ou ceci :
user_profile
user_profile_comments
organization_profile
organization_profile_comments
????
[^] # Re: logique à 2 niveaux
Posté par NeoX . Évalué à 2.
en france la difference entre un utilisateur et une entreprise se fait juste de la maniere suivante :
un utilisateur est une personne physique
une entreprise est une personne morale
du coup ton entreprise aura un profil comme n'importe quel utilisateur,
dans le pire des cas, tu ajoutes un champ "particulier/entreprise" au profil de l'utilisateur
[^] # Re: logique à 2 niveaux
Posté par shingo (site web personnel) . Évalué à 1.
Je viens d'avoir juste à l'instant le même raisonnement. Il faudrait qu'une entreprise soit un "user" et je rajoute comme tu le dis, un champ qui me permet de savoir si c un pro ou un particulier.
Du coup, ça va me simplifier la vie ! Merci beaucoup c'est la solution ultime !!!!
[^] # Re: logique à 2 niveaux
Posté par gaaaaaAab . É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)
# logique à 2 niveaux
Posté par NeoX . Évalué à 2.
ce que tu cherches, c'est plutot les noms des colonnes non ?
car dans ton cas, j'eviterais quand meme de faire un table de blogs pour chaque utilisateur,
et je ferais plutot :
un utilisateur, plusieurs profiles OK
mais avec une seule table
profilesqui contiendra les colonnes userid,champs1, champs2, avatar
les champs etant les données de l'utilisateur (pseudo, et autres infos)
l'avatar etant à prendre dans la table
avatarsdans la meme idée, une table
blogsune table
articlesune table
comments[^] # Re: logique à 2 niveaux
Posté par shingo (site web personnel) . Évalué à 1.
Le parfait exemple, serait un site comme Facebook. Dans ce cas, tu as des groupes, pages et membres. Par exemple, lorsqu'on ajoute des publications en tant que groupe ou page, où sont enregistrés les données ? Dans une table différente ou bien est-ce juste une question de clé étrangère (user_id à null, et group_id à 56 ?).
Je bosse sur un site communautaire, et j'aimerais permettre aux membres justement de publier du contenu en tant que page ou group, c'est pour cela que les membres ne sont pas les seuls à posséder des photos, articles, etc.
[^] # Re: logique à 2 niveaux
Posté par NeoX . Évalué à 2.
comme pour l'entreprise,
un groupe au sens facebook, c'est finalement un utilisateur à part sur lequel d'autres (les membres) peuvent venir ecrire sur le mur.
et pour une page, c'est un groupe avec un seul membre, le gestionnaire de la page :/
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.