locked
Probleme d'adresses? RRS feed

  • Question

  • Bonjour a tous
    J’ai 3 tables de personnes: students, parents, employees. Une école.
    J’ai une autre table pour les adresses, addresses.dbf, et les tables qui relient les unes aux autres : addr_stud.dbf, addr_par.dbf et addr_empl.dbf.
    Mon problème est que je ne sais pas comment créer un interface pour ajouter/éditer les adresses pour l’utilisateur.
    S’il peut choisir un étudiant et cliquer "Add Address", l’adresse qu’il veut ajouter peut déjà être enregistrée au nom d’un parent.
    Pour les parent, même problème : il choisit le père, qui n’a pas encore d’adresse enregistrée et click "Add". Mais l’adresse est peut être déjà la pour la mère.
    En plus, il y a des employés qui ont leur enfants dans cette école. Donc pour un élève, l’adresse peut déjà exister chez le père, la mère ou chez un employé. L’élève peut aussi habiter chez quelqu’un d’autre, auquel cas elle ne sera nulle part et il faudra l’ajouter a addresses.dbf.

    Quelqu’un a-t-il quelque conseil ? 


    Marcel
    mardi 7 septembre 2010 18:11

Réponses

  • le modèle de données que tu indiques est correct (il y en a d'autres). il te permet d'avoir plusieurs adresses pour un même étudiant

    il reste maintenant à remonter ces données à l'interface utilisateur.
    tu peux faire une vue

    SELECT        StudentName ,
                       Adress
           FROM   students
                      JOIN studentAdresses
                      ON     students.studentID = studentAddresses.studentID
                      JOIN adresses
                      ON     studentAdresses.addressID = adresses.addressID

    tu vas présenter cette vue sur un form comme ça te convient (par exemple un grid avec la liste des adresses de chaque étudiant, et un autre grid pour les adresses), et pour modifier / ajouter une adresse pour un étudiant, tu as aussi le choix de passer par un form enfant, ou de tout faire dans le grid 'adresses' du form que tu viens de faire.

     

    • Marqué comme réponse Marcel10 lundi 20 septembre 2010 11:00
    dimanche 19 septembre 2010 13:56

Toutes les réponses

  • Bonjour,

    pourrais-tu nous préciser la version de VFP que tu utilises, et nous donner les structures des tables, s'il te plait?

    mercredi 8 septembre 2010 09:45
  • Salut Michel
    Pardon pour le retard, j'avais des problèmes d'internet.
    Voila la structure des tables. Elle a change plusieurs fois car j'arrive pas a trouver une bonne solution. Et surtout je ne sais pas comment faire pour l'editing par l'utilisateur.
    J'aimerais bien quelques conseils: comment fait on ceci en général. Ce n'est une solution pour mon cas précisément que je voudrais, mais plutôt comment la plupart des bons programmeurs feraient cela.
    Quand on édit un student, faut-il un bouton spécial du genre "Get Address" ou "Add new address"? Un bouton qui ouvrira un nouveau formulaire ou on pourrait ajouter une adresse, on en choisir une qui existe déjà?
    Pour le moment, j'ai abandonne car je ne m'y retrouve pas. J'ai mis les adresses DANS la table students.dbf. Mais tout conseil est bienvenu. Merci.

    J'utilise VFP9.

    Addresses.dbf
    -------------
    -AddressID     PK
    -Address

    ###########################################
    students.dbf
    ------------
    -studentID     PK
    -studentName

    studentAddresses.dbf (table intermediaire)
    ------------------------------------------
    -ID autoinc
    -studentID -> relie a students.dbf
    -AddressID -> relie a addresses.dbf

    ###########################################
    parents.dbf
    -----------
    -parentID     PK
    -parentName

    parentAddresses.dbf (table intermediaire)
    -----------------------------------------
    -ID autoinc
    -parentID  -> relie a parents.dbf
    -AddressID -> relie a addresses.dbf

    ###########################################
    employees.dbf
    -------------
    -employeeID     PK
    -employeeName

    employeeAddresses.dbf (table intermediaire)
    -------------------------------------------
    -ID autoinc
    -employeeID -> relie a employees.dbf
    -AddressID  -> relie a addresses.dbf
    Marcel
    dimanche 19 septembre 2010 06:33
  • le modèle de données que tu indiques est correct (il y en a d'autres). il te permet d'avoir plusieurs adresses pour un même étudiant

    il reste maintenant à remonter ces données à l'interface utilisateur.
    tu peux faire une vue

    SELECT        StudentName ,
                       Adress
           FROM   students
                      JOIN studentAdresses
                      ON     students.studentID = studentAddresses.studentID
                      JOIN adresses
                      ON     studentAdresses.addressID = adresses.addressID

    tu vas présenter cette vue sur un form comme ça te convient (par exemple un grid avec la liste des adresses de chaque étudiant, et un autre grid pour les adresses), et pour modifier / ajouter une adresse pour un étudiant, tu as aussi le choix de passer par un form enfant, ou de tout faire dans le grid 'adresses' du form que tu viens de faire.

     

    • Marqué comme réponse Marcel10 lundi 20 septembre 2010 11:00
    dimanche 19 septembre 2010 13:56
  • Je vais essayer avec un grid. Je voulais eviter les grids, mais je finis par penser que c'est indispensable dans mon cas.

    Tu disais qu'il y a d'autres modeles. Sont-ils tres differents? Si oui, pourrais-tu donner un petit example, ou expliquer ce qui est different?


    Marcel
    dimanche 19 septembre 2010 15:25
  • Mais si tu ne veux pas de grids, tu peux parfaitement ne pas en utiliser, par exemple avec une barre de navigation pour afficher les students un par un, et une listbox pour afficher leurs adresses.

    pour les autres modèles de données, je pense par exemple à une table personnes (liée à une table adresses), avec une table TypePersonnes, et ta table students ne contient alors que les clés étrangères pointant sur personnes et typePersonnes. la table personnes comporterait une auto-jointure, ou bien tu peux ajouter une tables de multi-jointures personnes/personnes.

    quand tu cherches des modélisations de données, pense à regarder ce site : DatabaseAnswers.org, il est plein de ressources

     

    dimanche 19 septembre 2010 15:36

  • Ok, merci pour tes conseils et informations.

    J'ai commence avec 2 grids, c'est encore tres "basic" mais ca marche pour le moment. Si j'ai des problemes, je reviendrai sur ce thread. Une fois que cela marchera bien, je pourrai facilement changer pour des listbox ou autres.

    Pour les modeles, oui je vois ce que tu veux dire et j'ai essaye, mais c'etait encore plus complexe. J'y reviendrai peut-etre un jour. Mon modele a moi vient aussi plus ou moins de databaseAnswers.

    A ce propos, peut-etre une derniere question:

    http://www.databaseanswers.org/data_models/school_management_systems/school_management_system_physical.htm

    Dans cette image de dbAnswer, la table intermediaire student_addresses.dbf a la colonne "date_from" comme PK. Pourquoi? Des dates, il peut y en avoir des doubles, meme si c'est une datetime, pas vrai? Et pourquoi choisir la date comme PK? Peut-etre y a t-il un sens a cela, mais je ne le vois pas.

    Je suppose que ceci est la date a laquelle l'addresse a ete enregistree, et qui veut dire en meme temps qu'elle est encore active?

    Et pourquoi y a t-il un field address_details dans les 2 table student_addresses.dbf et addresses.dbf? Je ne vois pas ce qu'il fait dans student_addresses.dbf.


    Marcel
    dimanche 19 septembre 2010 17:01
  • bonjour,

    non, dans le modèle que tu regardes sur databaseAnswers, la table student_adresses n'a pas la pk sur date_from.

    La PK de cette table est constituée des 3 colonnes Student_ID, Adress_ID, Date_From.
    Si je comprends bien, l'auteur de ce modèle utilise 2 colonnes pour déterminer qu'une adresse est active: date_from doit être renseignée (fait partie de la pk, ne peut pas être null), et tant que date_to est null, la ligne est en activité.

    pour ta 2ème question, je suis d'accord avec toi, on peut se demander pourquoi. ou alors, il en faut un aussi dans Parent_Adresses, et dans ce cas, ça permet de considérer les détatils des adrersses de façon générique pour toutes les adresses, et en plus de façon spécifiques pour les adresses des students et pour les adresses des parents.

    lundi 20 septembre 2010 09:10