IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

 PostgreSQL Discussion :

recherche dans plusieurs tables


Sujet :

PostgreSQL

  1. #1
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    78
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 78
    Points : 37
    Points
    37
    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é
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    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
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    78
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 78
    Points : 37
    Points
    37
    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 confirmé Avatar de saymoneu
    Homme Profil pro
    Développeur Web
    Inscrit en
    Avril 2010
    Messages
    248
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 35
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : Avril 2010
    Messages : 248
    Points : 505
    Points
    505
    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é
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    78
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 78
    Points : 37
    Points
    37
    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é
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    Par défaut
    Quelles raisons motive le refus ?

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

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    78
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 78
    Points : 37
    Points
    37
    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é
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    Par défaut
    Et donc vous redeployez l'application sous postgresql ?
    A terme access va dégager ?

  10. #10
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Janvier 2008
    Messages
    78
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2008
    Messages : 78
    Points : 37
    Points
    37
    Par défaut
    A terme Access doit disparaitre, sauf que ça devrait prendre un an et demi ou deux.

  11. #11
    Expert confirmé
    Homme Profil pro
    Inscrit en
    Mai 2002
    Messages
    3 173
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 41
    Localisation : France, Rhône (Rhône Alpes)

    Informations forums :
    Inscription : Mai 2002
    Messages : 3 173
    Points : 5 345
    Points
    5 345
    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.

Discussions similaires

  1. Recherche dans plusieurs tables
    Par cyscek dans le forum Langage SQL
    Réponses: 6
    Dernier message: 22/05/2012, 21h42
  2. Recherche dans plusieurs tables
    Par vero3030 dans le forum Langage SQL
    Réponses: 10
    Dernier message: 18/10/2007, 14h21
  3. [MySQL] recherche dans plusieurs tables
    Par minimoof dans le forum PHP & Base de données
    Réponses: 2
    Dernier message: 07/08/2007, 08h58
  4. recherche dans plusieurs tables
    Par rostomides dans le forum Bases de données
    Réponses: 7
    Dernier message: 16/03/2007, 09h34
  5. Comment rechercher une chaine dans plusieurs tables ?
    Par tsing dans le forum Requêtes
    Réponses: 2
    Dernier message: 26/11/2005, 19h04

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo