en DAO , evec des requetes sql, quel est le principe des requetes
multiples ? je m'explique :
- je veux sélectionner d'abord uniquement les enregistrements qui ont
comme champ année : 2004
- ensuite je veux stocker le résultat et appliquer sur ce résultat
d'autres critères....
dois je les faire tous en même temps en utilisant INTO, ou dois je créer
une sous table sur laquelle je vais appliquer mes sous requetes ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc
"dav" a écrit dans le message de news:419f7566$0$7234$
en DAO , evec des requetes sql, quel est le principe des requetes multiples ? je m'explique :
- je veux sélectionner d'abord uniquement les enregistrements qui ont comme champ année : 2004 - ensuite je veux stocker le résultat et appliquer sur ce résultat d'autres critères....
dois je les faire tous en même temps en utilisant INTO, ou dois je créer une sous table sur laquelle je vais appliquer mes sous requetes ?
quel est le plus souple ?
Hello,
il n'y a pas de règle absolue, valable dans tous les cas. Les 2 solutions dont tu parles sont bonnes. Si une partie des données ne bouge pas, il peut être intéressant de stocker le résultat de la première requête dans une table temporaire pour ne pas recalculer à chaque fois, mais c'est un cas assez peu courant. En terme de souplesse, les 2 méthodes se valent. Disons qu'à choisir, je fais plus souvent tout en SQL, en une fois. Si je change ma requête, je ne dois changer que du SQL et pas de code du tout. Mieux, mes requêtes sont elles même stockées dans des tables. Bien souvent, pour mettre à jour une application, je ne dois re livrer que des scripts d'update (qui updatent les requêtes dans la table) et hop, le tour est joué.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"dav" <dav49400-spam@wanadoo.fr> a écrit dans le message de
news:419f7566$0$7234$8fcfb975@news.wanadoo.fr...
en DAO , evec des requetes sql, quel est le principe des requetes
multiples ? je m'explique :
- je veux sélectionner d'abord uniquement les enregistrements qui ont
comme champ année : 2004
- ensuite je veux stocker le résultat et appliquer sur ce résultat
d'autres critères....
dois je les faire tous en même temps en utilisant INTO, ou dois je créer
une sous table sur laquelle je vais appliquer mes sous requetes ?
quel est le plus souple ?
Hello,
il n'y a pas de règle absolue, valable dans tous les cas. Les 2
solutions dont tu parles sont bonnes. Si une partie des données ne
bouge pas, il peut être intéressant de stocker le résultat de la
première requête dans une table temporaire pour ne pas recalculer à
chaque fois, mais c'est un cas assez peu courant. En terme de
souplesse, les 2 méthodes se valent. Disons qu'à choisir, je fais plus
souvent tout en SQL, en une fois. Si je change ma requête, je ne dois
changer que du SQL et pas de code du tout. Mieux, mes requêtes sont
elles même stockées dans des tables. Bien souvent, pour mettre à jour
une application, je ne dois re livrer que des scripts d'update (qui
updatent les requêtes dans la table) et hop, le tour est joué.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"dav" a écrit dans le message de news:419f7566$0$7234$
en DAO , evec des requetes sql, quel est le principe des requetes multiples ? je m'explique :
- je veux sélectionner d'abord uniquement les enregistrements qui ont comme champ année : 2004 - ensuite je veux stocker le résultat et appliquer sur ce résultat d'autres critères....
dois je les faire tous en même temps en utilisant INTO, ou dois je créer une sous table sur laquelle je vais appliquer mes sous requetes ?
quel est le plus souple ?
Hello,
il n'y a pas de règle absolue, valable dans tous les cas. Les 2 solutions dont tu parles sont bonnes. Si une partie des données ne bouge pas, il peut être intéressant de stocker le résultat de la première requête dans une table temporaire pour ne pas recalculer à chaque fois, mais c'est un cas assez peu courant. En terme de souplesse, les 2 méthodes se valent. Disons qu'à choisir, je fais plus souvent tout en SQL, en une fois. Si je change ma requête, je ne dois changer que du SQL et pas de code du tout. Mieux, mes requêtes sont elles même stockées dans des tables. Bien souvent, pour mettre à jour une application, je ne dois re livrer que des scripts d'update (qui updatent les requêtes dans la table) et hop, le tour est joué.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
