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.

Bonjour,


Quel est votre MCD ?
Quel est votre MPD ?


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

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 ?

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.

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

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 :).

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'

---

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

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

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

Bah c'est le moment propice pour tout applatir.

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