Forum Programmation.autre Base de données et nombre de colonne variable ?

Posté par  (site web personnel) .
Étiquettes : aucune
0
22
sept.
2004
Bonjour les gens,
aujourd'hui le problème à bibi est le suivant :
Quel schéma de base permet de gérer des données dont les informations sont variables et dont certains champs peuvent être liés ou de manière plus pragmatique comment éviter une table avec des rajouts/suppression de colonne et dont certaines colonnes peuvent être liés et multiples occurences de types historique.

Un exemple : vous avez une base de donnée d'image et dessus vous avez plein d'info. Vous créer une table avec juste id_image et une table avec id_info,name_info,type_info.
Suffit d'une troisième table de liaison avec id_liaison, id_image, id_info, value, pourquoi id_liaison ? parceque vous pouvez avoir plusieurs valeurs

IMAGE
1

INFO
1|nom du fichier|string
2|chemin|string
3|personne sur la photo|string

LIAISON
1|1|1|"dscn0001.jpg"
2|1|3|"Tonton René"
3|1|3|"Mamie Lulu"


Maintenant comment prendre en compte que certaines valeurs peuvent être lié ?
Si je veux un historique de mes envois avec la date et les destinataires ?

Je rajoute à INFO
4|destinataire|email
5|date d'envoie|date

Est ce que je créé une table liaison de liaison avec id_liaison_liaison, id_info ?

LIAISON_LIAISON
1|1
1|2
2|4
2|5

Mes requetes risquent de plus être très catholiques :)

Un cas d'école ? Une idée ? Un piste ? Une inscription en cours du soir ?

  • # question bête

    Posté par  . Évalué à 2.

    as tu fais un schéma entité association?
    comme ça, je dirais non, parce que sinon, tu te poserais pas autant de questions au moment de la définition des relations.
    commence par avoir un bon schéma E/A, c'est à dire qui décrit exactement les entités (sans attribut artificiel comme les id) et les associations.
    Ensuite, les relations découlent naturellement de ce schéma par des règles simples et sans ambiguité.
    Vérifie que le résultat obtenu est bien normalisé, sinon, c'est que tu as une erreur de conception quelque part.
    Parfois, à partir d'une relation pas normale, tu te rends compte que ton schéma E/A dont t'étais content est faux ...

    pour répondre à ta question donc, oui j'ai une piste: un schéma E/A ;)

    • [^] # Re: question bête

      Posté par  (site web personnel) . Évalué à 1.

      Je pense que le problème est plus "général" puisque dans l'exemple donnée il n'y a qu'une entité. Imagine juste des images avec plein d'infos de types et valeurs variantes et avec des liens entre ces infos variants aussi.
      Ca doit être le même problème dans les gestions de configs de PC, une seule entité mais plein d'options variables.

      • [^] # Re: question bête

        Posté par  . Évalué à 1.

        mouais, je comprend ce que tu veux faire ...
        je ne sais pas s'il existe des équivalents.
        En tout cas, si tu veux te lancer dans un truc aussi complexe, raison de plus pour modéliser proprement avec un schéma conceptuel avant de foncer dans le schéma relationnel ;)

        • [^] # Re: question bête

          Posté par  . Évalué à 1.

          je re répond parce que j'avais lu ta réponse un peu vite ...

          non, il n'y a pas qu'une seule entité dans ton exemple

          une date d'envoi par mail n'est pas lié à une photo.

          y aurais plutot (par exemple) une entité photo d'un coté, une entité destinataire et une association entre les deux, l'association mail avec un attribut date pour l'association.

          • [^] # Re: question bête

            Posté par  (site web personnel) . Évalué à 1.

            Le problème c'est je ne veux pas créer une table pour remplacer une colonne ...
            A chaque nouvelle info : une table ?

            • [^] # Re: question bête

              Posté par  . Évalué à 1.

              je suis d'accord avec toi. C'est normal que tu ne veuilles pas créer une table pour remplacer une colonne, mais là, les associations entre tes entités (que tu refuses de modéliser mais qui existent quand même) ne sont pas de cardinalité 0-1 ou 1-1. Du coup, la table NE peut PAS être équivalente à une colonne.

              j'ai discuté de ça avec un collègue. Il en sort que si tu veux pouvoir définir dynamiquement des relations entre différents type d'infos, ce que tu cherches à faire en fait, c'est un sgbd, et t'as de la chance, y'en a pleins ;)

              • [^] # Re: question bête

                Posté par  (site web personnel) . Évalué à 1.

                J'ai avancé depuis ce matin et c'est vrai que ça ressemble un peu trop à mon gout à un sgbd ...
                Grrrrr ... Jecontinue à chercher ...

  • # Modéliser ... toutjours modéliser

    Posté par  . Évalué à 1.

    Comme dit plus haut, il semble que tu as adopté la technique du 'je fonce dans le tas !'.

    Tu peux arriver à tes fins de cette manière ... avec énormément de chance !
    Ca peux suffire un temps mais si après (dans 1 jour, 2 jours ou 3 ans) tu décides d'ajouter de nouvelles caractéristiques : là tu vas en baver à mort.

    Ma première interrogation est ta table IMAGE qui ne contient qu'un champ. Je n'en ai jamais trouvé l'utilité, ça veut dire qu'il faut regrouper avec quelquechose d'autre.

    Ce que je ferais (simple suggestion simpliste) par exemple, c'est (en supposant que j'ai compris)
    IMAGE : id, fichier, chemin
    INDIVIDU : id, nom, prenom, email
    PHOTO : image, individu
    HISTORIQUE : id, image, individu, date_envoi

    Explications :
    Une image est définie par un identifiant, le nom de fichier et le chemin.
    Un individu est défini par un identifiant, ses nom, prenom et email
    Une photo présente un couple image individus (sur une image peuvent figurer plusieurs individus et un individu peut figurer sur plusieurs images)
    L'historique indique quelle image a été envoyée quand à quel individu.

    Les requêtes devraient être déjà plus catholiques avec ce schéma :)

    @++

    P.S : Ce ne sont que des pistes i.e ne pas prendre ça pour code comptant.

    • [^] # Re: Modéliser ... toutjours modéliser

      Posté par  (site web personnel) . Évalué à 1.

      Dans ton modéle, rajouter une info sur les photos implique de rajouter une colonne dans image et créer une nouvelle table, c'est ce que je veux éviter.

      • [^] # Re: Modéliser ... toutjours modéliser

        Posté par  . Évalué à 1.

        t'as un exemple d'info sous le clavier ?

        • [^] # Re: Modéliser ... toutjours modéliser

          Posté par  (site web personnel) . Évalué à 1.

          lieu de prise
          traitement et date

          • [^] # Re: Modéliser ... toujours modéliser

            Posté par  . Évalué à 1.

            Moi, je rajouterais le lieu de prise, le traitement et la date plutôt dans la table image (s'il y a 25 individus sur une photos, tous ont été photographiés au même endroit au même moment non ?).

            Cela dit, c'est peut-être ma dénommination tes tables qui ne te semble pas claire, je recommence :
            PHOTO : id, fichier, chemin, lieu, traitement, date
            INDIVIDU : id, nom, prenom, email
            PRESENT : image, individu
            HISTORIQUE : id, image, individu, date_envoi

            Il ne me semble pas qu'il faille systématiquement ajouter une table pour ça.

            Au fait, pourquoi tiens-tu absolument à éviter la création de nouvelles tables ?

            • [^] # Re: Modéliser ... toujours modéliser

              Posté par  (site web personnel) . Évalué à 1.

              Donc tu rajoutes des colonnes à la table ...
              Imagines que tu as 10 000 photos et 200 champs d'infos, la gueule de la table :)
              Le lendemain, 206 champs d'info et une semaine après 240 champs d'info. Avec ton schéma, ça se joue à coup de alter table, create table, etc., je cherche un schéma stable et prenant en compte les champs infos avec des select, update, insert, etc.

              Vous avez tous les 2 faits des modeles a partir des exemples sans prendre en compte que le nombre d'info est variable.

              Je trouve rien sur le net ... Je suis pourtant sùr que ça doit être un cas existant.

              • [^] # J'y vois peut-être un peu plus clair ...

                Posté par  . Évalué à 3.

                Tu dis en gros que tu as un nombre de propriétés inconnues au départ et que tu rajoutes au fur et à mesure des besoins.
                (je sais ... faut expliquer longtemps pour que je comprenne vite ...)

                Je sens que tu ne vas pas aimer ma nouvelle idée :
                1) créer une table des propriétés avec identifiant et nom de la propriété
                2) table info(id, image, propriété, valeur)

                Si tu as 200 infos sur une image, tu as 200 enregistrements dans la table info pour cette image.
                L'inconvénient est que tu dois alors avoir un champ valeur fourre-tout : par exemple placer lieu, traitement et date indifférement dans un champ texte.
                Pour les traitements, il faudrait alors vraisemblablement introduire un champ supplémentaire permettant de supposer le type du contenu du champ fourre-tout afin d'automatiser autant que possible.

                J'ai compris cette fois ?

                • [^] # Re: J'y vois peut-être un peu plus clair ...

                  Posté par  (site web personnel) . Évalué à 1.

                  Il a compris ;p

                  Donc tu arrives à peu près à ce que j'ai proposé au départ ...

                  Pour les champs c'est pas grave, ça se gère facilement.
                  Sqlite par exemple gère tout en string ...

                  Par contre, le problème des liens entre champs info reste. Si je reprends l'exemple des envois, le 20 j'envoie à tata et le 21 j'envoie à soeur, avec ton schéma, j'ai une table comme ça :

                  INFO
                  1|"dscn001.jpg"|"envoi"|"20/09/2004"
                  2|"dscn001.jpg"|"destinataire"|"tata"
                  3|"dscn001.jpg"|"envoi"|"21/09/2004"
                  4|"dscn001.jpg"|"destinataire"|"soeur"

                  comment lier chez champs ?

                  La solution que j'avais pensé était la table de LIAISON_LIAISON du post original.

                  Je suis presque embété que tu arrives à la même solution pour la première partie :)

                  • [^] # Alors là ?

                    Posté par  . Évalué à 2.

                    Je ne comprends pas ce que tu veux dire par "le problème des liens entre champs info reste".

                    Tu pourrais donner un exemple concret stp !
                    (ce n'est peut-être qu'une impression mais tes "liaisons' n'auraient-elles pas un rapport avec les clés étrangères ou avec les jointures ?)

                    • [^] # Re: Alors là ?

                      Posté par  (site web personnel) . Évalué à 1.

                      Dans le dernier exemple de INFO les id 1 et 2 sont liés comme 3 et 4.
                      Si quelqu'un doit rentrer un envoi, il doit rentrer une date.

                      • [^] # Ultime suggestion

                        Posté par  . Évalué à 2.

                        Maintenant je saisis mieux (c'est pas trop tôt)

                        A mon avis, tu ne vas pas aimer ma suggestion (pour changer ;-))

                        Le nombre de propriétés que tu gères est à priori sujet à des changements. Je suppose donc que certaines infos sont liées entre-elles et d'autres pas i.e, par exemple, une propriété 'license' ne dépend par d'une autre contrairement à envoi et destinaire.

                        Il est clair que la BD ne va pas deviner toute seule s'il y a un lien ou non. Pour faire ce lien explicite sans qu'il y ait lieu de multiplier les tables et les relations ... il faudrait multiplier les vues qui seraient donc chargées de dispatcher les informations dans la table (à l'aide d'une règle visiblement).

                        Toujours pas satisfait, je m'en doute ...

                        • [^] # Re: Ultime suggestion

                          Posté par  (site web personnel) . Évalué à 1.

                          Je m'approche (ça chauffe, ça chauffe) d'un schéma qui, apparement, peut me satisfaire, si ça colle, je le poste ici :)
                          Merci à tous en tout cas :)

                  • [^] # Re: J'y vois peut-être un peu plus clair ...

                    Posté par  (site web personnel) . Évalué à 1.

                    Tu rajoutes un timestamp (ou un ID issu d'une séquence) dans ta table paramètre pour tous les paramètres qui sont issus de la même "action", ca te donne :


                    INFO
                    1|125489653254|"dscn001.jpg"|"envoi"|"20/09/2004"
                    2|125489653254|"dscn001.jpg"|"destinataire"|"tata"
                    3|125489655555|"dscn001.jpg"|"envoi"|"21/09/2004"
                    4|125489655555|"dscn001.jpg"|"destinataire"|"soeur"


                    Tu peux ainsi regrouper tes paramètres. Si c'est un timestamp, tu pourras même extraire les paramètres à partir d'une certaine date.

                    Sinon je rajouterai une table intermédiaire : "Action". Sur une "photo" tu fais une "action" à une certaine date. Pour une "action" tu as des "paramètres" (les paramètres pointent donc vers l'action, qui pointe vers la photo). En plus pour chaque "action" tu peux ajouter une table pour définir les paramètres autorisés. Et ainsi pour chaque "définition de paramètre" ajouter des méta-data (type, longueur, conditions, etc.) On peut aller loin comme ca ;-)

                    Je crois qu'un bon modèle E/A -comme suggéré plus haut - t'aidera en effet grandement à éclaircir ce que tu attends de ta bdd

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.