Filtre en SQL

Bonsoir,

Données :

J'ai une table qui contient le personnel d'une boite autour de laquelle gravitent plusieurs autres tables telles que Absences, Salires, Prêts, Carrières etc ..

La question :

Je voudrais placer un filtre (en SQL), à la disposition de l'utilisateur, sur la table Personnel sur les infos qu'elle contient mais aussi sur les infos contenues dans les tables sus-citées.

Est-il judicieux de joindre toutes les tables ou bien y aurait-il une meilleure idée ? Je pense aux délais de réponses.


Merci.

W7, D7, FB2.5, Zeos 7.1.2

Bonjour,

Citation:

---

Envoyé par akli_agha

Données :

J'ai une table qui contient le personnel d'une boite autour de laquelle gravitent plusieurs autres tables telles que Absences, Salires, Prêts, Carrières etc ..

La question :

Je voudrais placer un filtre (en SQL), à la disposition de l'utilisateur, sur la table Personnel sur les infos qu'elle contient mais aussi sur les infos contenues dans les tables sus-citées.

Est-il judicieux de joindre toutes les tables ou bien y aurait-il une meilleure idée ? Je pense aux délais de réponses.

---

Il manque quelques informations complémentaires :

Les données affichées restent elles les mêmes quelque soit la (ou les) condition de filtre ?
Les critères de filtre sont ils mutuellement exclusifs ou possiblement associatifs ?
Quel est le volume maximal de données qui pourraient être extraites hors filtre (le nombre de personnes en l'occurrence, 10, 100, 1000, 10000, 100000, +) ?

Bonjour,

. Juste un simple affichage à l'aide du couple Query/DBGrid
. Les filtres sont inclusifs (env. 20 critères) au choix de l'utilisateur
. Volume env. 100 000 enreg.
Merci

Bonjour,

Query, DBGrid, Filtre :roll: des termes Delphi qui n'ont pas grand choses à voir avec Firebird sensu-stricto !
maintenant s'il s'agit d'avoir

Citation:

---

les sur la table Personnel sur les infos qu'elle contient mais aussi sur les infos contenues dans les tables sus-citées.

---

sans que l'utilisateur ait à faire les jointures etc... et que pour le programme soit facile à lire une vue (VIEW) est certainement à envisager, à moins qu'une PROCEDURE paramétrée renvoyant des données , voire une combinaison des deux ? la vue créant le BLR nécessaire pour l'ensemble des données , la procédure la partie traitement de la clause WHERE (le "filtre")
évidemment, comme si je le présume tous les critères ne sont pas toujours donnés, dans cette procédure il y aura certainement un EXECUTE STATEMENT à faire

Delphi oui mais avec une base FB !

En fait, les requêtes, c'est moi qui les mets en place. L'utilisateur saisira ses choix dans des zones de saisie contenues dans une forme.

Dois-je comprendre que je dois prévoir dans des SP et Views tous les cas de figure en plus des clauses WHERE ?


Merci.

[QUOTE=akli_agha;8622238]Delphi oui mais avec une base FB ![QUOTE]
exact mais il s'agit d'une question de codage pas de comportement Firebird ou de SQL sensu stricto

soit via delphi ,
on utilise un bout de code qui va créer la requête
plusieurs solutions selon les composants utilisés :
- macros si possibilité (et avec ZEOS c'est le cas)
- format dans le cas contraire

Citation:

---

En fait, les requêtes, c'est moi qui les mets en place.

---

Comme c'est vous qui les faites c'est à vous de voir

Citation:

---

L'utilisateur saisira ses choix dans des zones de saisie contenues dans une forme.

---

donc la requête en code dans le programme Delphi sera paramétrée

Soit on prépare une partie qui va se faire sur le serveur donc via Firebird
et dans ce cas on va utiliser vues et/ou procédures
et ,pour interroger la vue ou la procedure, via Delphi, on utilisera là également une requête paramétrée

Citation:

---

Dois-je comprendre que je dois prévoir dans des SP et Views tous les cas de figure en plus des clauses WHERE ?

---

ce n'est pas ce que j'ai écrit mais il faut considérer une ou deux choses dont le temps d'exécution et la charge serveur
le fait que la vue comme la procédure seront des élément compilés et prêts ne sont pas à négliger surtout s'il s'agit de requêtes complexes

Ok, merci Sergio pour tes précieux conseils.

Je m'y mettrai.