+ Répondre à la discussion
Affichage des résultats 1 à 11 sur 11
  1. #1
    Invité régulier
    Inscrit en
    janvier 2008
    Messages
    78
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 78
    Points : 9
    Points
    9

    Par défaut recherche dans plusieurs tables

    Bonjour,

    J'ai une base PostegreSQL, que je commence à apprivoiser, et je dois faire un choix sur la manière d'accéder aux données. Pour être plus clair, j'ai 15 tables utilisateurs (je ne peux pas faire autrement, le gérant veut garder cette différentiation, une table par lieu).

    Du coup, lors d'une authentification, j'ai deux choix :
    - rajouter un champ "ville" en plus du login et du mot de passe, et chercher uniquement dans la table correspondante, mais avec des risques d'erreurs de la part de l'utilisateur
    - faire une recherche sur toutes les tables en même temps

    Ma question porte sur ce second choix : il y a environ 300 utilisateurs par table, est-ce que cela ralentira beaucoup le trafic (ie est-ce que les requêtes de login seront longues) si je cherche parmi 300*15 utilisateurs ?

    J'aimerai éviter le premier choix, mais je préférai me renseigner d'abord ici, vu que je n'ai aucune idée de la puissance et de la manière de chercher de PostegreSQL.

  2. #2
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 117
    Points : 5 157
    Points
    5 157

    Par défaut

    Bonjour,


    Quel est votre MCD ?
    Quel est votre MPD ?


    Un petit jeu de donnée pour comprendre votre problème ?

  3. #3
    Invité régulier
    Inscrit en
    janvier 2008
    Messages
    78
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 78
    Points : 9
    Points
    9

    Par défaut

    Je suis peu au point côté théorique, mais je vais essayer de donner les infos que je peux (en espérant que ça colle) :

    Une table aura les champs :
    ID
    user
    password
    name
    et d'autres infos personnelles

    Tous les champs sont des chaînes de caractère, sauf l'ID qui est un nombre. L'ID peut être le même d'une table à une autre, mais pas dans une même table bien évidemment.

    J'en profite pour rajouter une question, que j'ai oublié quand j'ai posté le sujet : est-il possible de savoir le nom de la table dans lequel la requête a trouvé la réponse ?

    Ex : un utilisateur de Lille se log, la requête SQL cherche dans les 15 tables, et trouve l'utilisateur dans la table utilisateurs_lille. Puis-je récupérer le nom de la table, où dois-je forcément rajouter un champ "ville" dans ma table, sachant que pour tous les utilisateurs de cette table ça sera la même ?

  4. #4
    Membre éprouvé Avatar de saymoneu
    Homme Profil pro
    Développeur Web
    Inscrit en
    avril 2010
    Messages
    247
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 26
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Communication - Médias

    Informations forums :
    Inscription : avril 2010
    Messages : 247
    Points : 490
    Points
    490

    Par défaut

    Ca ne me semble vraiment pas adapté, faudrait expliquer à ton boss que ça n'a aucun intéret de faire différentes tables selon la ville mais que ça n'apporte que des inconvénients, comme en effet la lenteur de l'exécution de la requête. Il espère surement pouvoir continuer de voir ses utilisateurs par ville, pour ça tu peux lui suggérer l'utilisation de vues.

    Comme tu proposais, rajouter un champ ville pourrait être judicieux pour diviser par 15 le temps d'exécution de la requête, mais il faut s'assurer que l'utilisateur ne se trompera pas en écrivant la ville, je te suggère donc une liste déroulante des 15 villes.

  5. #5
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 117
    Points : 5 157
    Points
    5 157

    Par défaut

    La modélisation est pourri.

    Faudrai voir les règles de gestion.

    D'un point de vue conceptuel il y a deux approches :

    - Soit un utilisateur peut être associée à une seule ville :
    Utilisateur-1,1-----Associé-----0,n-Ville

    => transcription MPD :
    Utilisateur (uti_id, #vil_id, .....)
    Ville (vil_id, vil_nom, ....)

    (clef primaire : soulignée, clef étrangère : #)


    -Soit un utilisateur peut être associée à plusieurs ville :
    Utilisateur-1,n-----Associé-----0,n-Ville

    => Transcription MPD :
    Utilisateur (uti_id, .....)
    Ville (vil_id, vil_nom, ....)
    A_uti_vil(#uti_id, #vil_id)

    Une autre approche que celle-ci est contre productive et pourra entrainer des erreurs.


    Si malgrès tout ceci, votre client ne veut pas changer je pense que le mieux serai de passer par une vue.

    Code :
    1
    2
    3
    4
    5
    6
    7
    8
     
    create view vue_utilisateur as 
    select id, nom, 'ma_ville1'
    from utilisateur_ma_ville1
    union all
    select id, nom, 'ma_ville2'
    from utilisateur_ma_ville2
    ...
    Et faire une requête dessus

  6. #6
    Invité régulier
    Inscrit en
    janvier 2008
    Messages
    78
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 78
    Points : 9
    Points
    9

    Par défaut

    Un utilisateur ne peut être que dans une ville. En fait, pour expliquer ce fait, l'utilisateur est un élève, d'une filiale d'école implantée un peu partout.

    Je suis d'accord sur le fait qu'une seule table ça serait mieux, mais ça ne semble pas négociable pour le moment. Je vais continuer à y réfléchir et à essayer de le faire changer d'avis, on verra bien .

  7. #7
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 117
    Points : 5 157
    Points
    5 157

    Par défaut

    Quelles raisons motive le refus ?

    s'il veut absolument une table par ville .... créer des vues !!

    Code :
    1
    2
    3
    4
    5
    6
     
    create view utilsiateur_nantes as 
    select *
    from utilisateur a
    inner join ville b on a.vil_id = b.vil_id
    where vil_nom = 'nantes'

  8. #8
    Invité régulier
    Inscrit en
    janvier 2008
    Messages
    78
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 78
    Points : 9
    Points
    9

    Par défaut

    Il ne veut pas mélanger ses bases, sachant qu'à la base, tout est saisi sous access.

    D'ailleurs, à ce niveau ça amène une autre question. J'ai transféré une des bases access sous postgresql sans aucun problème. Si maintenant j'en transfère une autre, est-ce que je peux fusionner les deux dans postgresql ? (et après ça fusionner les 15 ensemble).

  9. #9
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 117
    Points : 5 157
    Points
    5 157

    Par défaut

    Et donc vous redeployez l'application sous postgresql ?
    A terme access va dégager ?

  10. #10
    Invité régulier
    Inscrit en
    janvier 2008
    Messages
    78
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 78
    Points : 9
    Points
    9

    Par défaut

    A terme Access doit disparaitre, sauf que ça devrait prendre un an et demi ou deux.

  11. #11
    Expert Confirmé Sénior
    Homme Profil pro
    Inscrit en
    mai 2002
    Messages
    3 117
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 32
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : mai 2002
    Messages : 3 117
    Points : 5 157
    Points
    5 157

    Par défaut

    Bah c'est le moment propice pour tout applatir.

    Refaire le modèle de donné, préparer une migration des bases access, etc.

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •