Forum Programmation.SQL Question sur le nommage des tables

Posté par (page perso) . Licence CC by-sa
Tags : aucun
0
7
mar.
2015

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 . É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 (page perso) . É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 . É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 . É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 (page perso) . É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 . É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 (page perso) . É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 . É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 :

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

  • # logique à 2 niveaux

    Posté par . É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 profiles
    qui 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 avatars

    dans la meme idée, une table blogs
    une table articles
    une table comments

    • [^] # Re: logique à 2 niveaux

      Posté par (page perso) . É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 . É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 à ceux qui les ont postés. Nous n'en sommes pas responsables.