-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de
400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR =
MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de
400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR =
MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de
400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR =
MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
Salut
Et donc, c'est quoi ton problème ???
Si ce n'est que ça me paraît bien long... ;-))
@+
Jessy Sempere - Access MVP
Salut
Et donc, c'est quoi ton problème ???
Si ce n'est que ça me paraît bien long... ;-))
@+
Jessy Sempere - Access MVP
Salut
Et donc, c'est quoi ton problème ???
Si ce n'est que ça me paraît bien long... ;-))
@+
Jessy Sempere - Access MVP
-----Message d'origine-----
Sinon juste pour info, inutile de spécifier les alias
dans ta 2ème
instruction Select...
(fallait bien que je dise un truc dont je suis sûr... ;-
-----Message d'origine-----
Sinon juste pour info, inutile de spécifier les alias
dans ta 2ème
instruction Select...
(fallait bien que je dise un truc dont je suis sûr... ;-
-----Message d'origine-----
Sinon juste pour info, inutile de spécifier les alias
dans ta 2ème
instruction Select...
(fallait bien que je dise un truc dont je suis sûr... ;-
Mais c'est impressionnant la différence entre
WHERE champ1 =X OR champ2 = X
et
WHERE champ1 =X
UNION
WHERE champ2 = X
j'essaye de comprendre pourquoi personne ne me l'avait
jamais dit !!
Mais c'est impressionnant la différence entre
WHERE champ1 =X OR champ2 = X
et
WHERE champ1 =X
UNION
WHERE champ2 = X
j'essaye de comprendre pourquoi personne ne me l'avait
jamais dit !!
Mais c'est impressionnant la différence entre
WHERE champ1 =X OR champ2 = X
et
WHERE champ1 =X
UNION
WHERE champ2 = X
j'essaye de comprendre pourquoi personne ne me l'avait
jamais dit !!
-----Message d'origine-----
Par contre je veux bien pour testé chez moi que tu
m'envois
la base avec les 3 tables et les deux requêtes par contre
sous
Access 97 si possible biensûr... ;-)
-----Message d'origine-----
Par contre je veux bien pour testé chez moi que tu
m'envois
la base avec les 3 tables et les deux requêtes par contre
sous
Access 97 si possible biensûr... ;-)
-----Message d'origine-----
Par contre je veux bien pour testé chez moi que tu
m'envois
la base avec les 3 tables et les deux requêtes par contre
sous
Access 97 si possible biensûr... ;-)
-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de
400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR >MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de
400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR >MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de
400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR >MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
Salut,
La raison du problème semble toute simple. La jointure est effectuée AVANT
le where. Donc, il y a comparaisons entre plusieurs champs, "l'explosion" du
join (une possibilité de 400 000 au carré, j'apelle cela une explosion)
est emmagasinée temporairement, et de cette explosion, établie, on ne
conserve, par sélection de critère WHERE, que quelques individus. Ressources
mal utilisées!
Il serait plus astucieux, dans ce cas, de faire le critère AVANT la
jointure:
SELECT * FROM makt WHERE maktx LIKE [Critere]
dans une requête, S1, pareil pour mfrpn LIKE [Critere], dans une requête
S2 (ou la même requête S1, si c'est de la même table). Cette requête
implique maitenant beaucoup MOINS que 400 000 enregistrement, probablement
100 000, non (mon estimé est basé sur des hypothèses un peu farfelues, mais
également de par les chiffres que tu avances: 100k = 400k * ( 170 /
(18*0.5) ) ^0.5) ?
Utiliser S1 ( et S2 si applicable) au lieu des tables originales, avec une
syntaxe voisine de la première requête, sans sa condition WHERE maintenant
inutile, devrait alors redonner un temps d'exécution d'une dizaine de
secondes (deux fois moins long que la requête UNION), voire mieux (surtout
si les requêtes S1 et S2 retournent en deça de 100k-enregistrements).
Si tu utilises MS SQL Server, tu peux faire remonter le critère du genre:
champ=constante
DANS la clause ON appropriée du join, cela aura le même effet. Avec Jet, on
ne peut pas, car Jet repasse derrière nous et redescend ce critère dans le
WHERE, à moins de procéder par requêtes cascadées, comme proposé, ou par
tables virtuelles (ce qui est la même chose, dans le fond).
Espérant être utile,
Vanderghast, Access MVP
"Arnaud [lwa]" wrote in message
news:2bc2301c468b9$873f7d60$
oups désolé message parti trop vite avec l'interface
WEB....et avant qu'elle apparaisse ....
je continue donc :
alors que la requête UNION ci-dessous
retourne le même résultat en 18 secondes au lieu de 170.
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR = MBEW.MATNR
WHERE MAKTX Like [Critere]
UNION SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR = MBEW.MATNR
WHERE MFRPN Like [Critere];
ps : DISTINCT inutile dans une requête UNION,
mais pas de différence notoire entre les temps dexécution
d'un SELECT et par rapport à un SELECT DISTINCT.
--
Bonne journée
Arnaud
http://memoaccess.free.fr-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR > >MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
Salut,
La raison du problème semble toute simple. La jointure est effectuée AVANT
le where. Donc, il y a comparaisons entre plusieurs champs, "l'explosion" du
join (une possibilité de 400 000 au carré, j'apelle cela une explosion)
est emmagasinée temporairement, et de cette explosion, établie, on ne
conserve, par sélection de critère WHERE, que quelques individus. Ressources
mal utilisées!
Il serait plus astucieux, dans ce cas, de faire le critère AVANT la
jointure:
SELECT * FROM makt WHERE maktx LIKE [Critere]
dans une requête, S1, pareil pour mfrpn LIKE [Critere], dans une requête
S2 (ou la même requête S1, si c'est de la même table). Cette requête
implique maitenant beaucoup MOINS que 400 000 enregistrement, probablement
100 000, non (mon estimé est basé sur des hypothèses un peu farfelues, mais
également de par les chiffres que tu avances: 100k = 400k * ( 170 /
(18*0.5) ) ^0.5) ?
Utiliser S1 ( et S2 si applicable) au lieu des tables originales, avec une
syntaxe voisine de la première requête, sans sa condition WHERE maintenant
inutile, devrait alors redonner un temps d'exécution d'une dizaine de
secondes (deux fois moins long que la requête UNION), voire mieux (surtout
si les requêtes S1 et S2 retournent en deça de 100k-enregistrements).
Si tu utilises MS SQL Server, tu peux faire remonter le critère du genre:
champ=constante
DANS la clause ON appropriée du join, cela aura le même effet. Avec Jet, on
ne peut pas, car Jet repasse derrière nous et redescend ce critère dans le
WHERE, à moins de procéder par requêtes cascadées, comme proposé, ou par
tables virtuelles (ce qui est la même chose, dans le fond).
Espérant être utile,
Vanderghast, Access MVP
"Arnaud [lwa]" <anonymous@discussions.microsoft.com> wrote in message
news:2bc2301c468b9$873f7d60$a401280a@phx.gbl...
oups désolé message parti trop vite avec l'interface
WEB....et avant qu'elle apparaisse ....
je continue donc :
alors que la requête UNION ci-dessous
retourne le même résultat en 18 secondes au lieu de 170.
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR = MBEW.MATNR
WHERE MAKTX Like [Critere]
UNION SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR = MBEW.MATNR
WHERE MFRPN Like [Critere];
ps : DISTINCT inutile dans une requête UNION,
mais pas de différence notoire entre les temps dexécution
d'un SELECT et par rapport à un SELECT DISTINCT.
--
Bonne journée
Arnaud
http://memoaccess.free.fr
-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de
400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR > >MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
Salut,
La raison du problème semble toute simple. La jointure est effectuée AVANT
le where. Donc, il y a comparaisons entre plusieurs champs, "l'explosion" du
join (une possibilité de 400 000 au carré, j'apelle cela une explosion)
est emmagasinée temporairement, et de cette explosion, établie, on ne
conserve, par sélection de critère WHERE, que quelques individus. Ressources
mal utilisées!
Il serait plus astucieux, dans ce cas, de faire le critère AVANT la
jointure:
SELECT * FROM makt WHERE maktx LIKE [Critere]
dans une requête, S1, pareil pour mfrpn LIKE [Critere], dans une requête
S2 (ou la même requête S1, si c'est de la même table). Cette requête
implique maitenant beaucoup MOINS que 400 000 enregistrement, probablement
100 000, non (mon estimé est basé sur des hypothèses un peu farfelues, mais
également de par les chiffres que tu avances: 100k = 400k * ( 170 /
(18*0.5) ) ^0.5) ?
Utiliser S1 ( et S2 si applicable) au lieu des tables originales, avec une
syntaxe voisine de la première requête, sans sa condition WHERE maintenant
inutile, devrait alors redonner un temps d'exécution d'une dizaine de
secondes (deux fois moins long que la requête UNION), voire mieux (surtout
si les requêtes S1 et S2 retournent en deça de 100k-enregistrements).
Si tu utilises MS SQL Server, tu peux faire remonter le critère du genre:
champ=constante
DANS la clause ON appropriée du join, cela aura le même effet. Avec Jet, on
ne peut pas, car Jet repasse derrière nous et redescend ce critère dans le
WHERE, à moins de procéder par requêtes cascadées, comme proposé, ou par
tables virtuelles (ce qui est la même chose, dans le fond).
Espérant être utile,
Vanderghast, Access MVP
"Arnaud [lwa]" wrote in message
news:2bc2301c468b9$873f7d60$
oups désolé message parti trop vite avec l'interface
WEB....et avant qu'elle apparaisse ....
je continue donc :
alors que la requête UNION ci-dessous
retourne le même résultat en 18 secondes au lieu de 170.
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR = MBEW.MATNR
WHERE MAKTX Like [Critere]
UNION SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR = MBEW.MATNR
WHERE MFRPN Like [Critere];
ps : DISTINCT inutile dans une requête UNION,
mais pas de différence notoire entre les temps dexécution
d'un SELECT et par rapport à un SELECT DISTINCT.
--
Bonne journée
Arnaud
http://memoaccess.free.fr-----Message d'origine-----
Bonjour,
Une constatation simple sur 2 requêtes impliquant pour
l'exemple 1 table de 700000 enregistrements et 2 tables
de400000 enregeistrements :
Résultat obtenu au bout de 170 Secondes
SELECT MARA.MATNR AS Article,
MAKTX AS Designation,
MTART AS Type,
MATKL AS GM,
BISMT AS Ancien_No,
MFRPN AS Reference,
MFRNR AS Fab_Frs,
BWKEY AS Division,
BKLAS AS CV
FROM (MARA INNER JOIN MAKT
ON MARA.MATNR = MAKT.MATNR)
INNER JOIN MBEW
ON MARA.MATNR > >MBEW.MATNR
WHERE MAKTX Like [Critere]
or MFRPN Like [Critere];
.
-----Message d'origine-----
Salut,
La raison du problème semble toute simple. La jointure
est effectuée AVANT
le where. Donc, il y a comparaisons entre plusieurs
champs, "l'explosion" du
join (une possibilité de 400 000 au carré, j'apelle
cela une explosion)
est emmagasinée temporairement, et de cette explosion,
établie, on ne
conserve, par sélection de critère WHERE, que quelques
individus. Ressources
mal utilisées!
Il serait plus astucieux, dans ce cas, de faire le
critère AVANT la
jointure:
SELECT * FROM makt WHERE maktx LIKE [Critere]
dans une requête, S1, pareil pour mfrpn LIKE [Critere],
dans une requête
S2 (ou la même requête S1, si c'est de la même table).
Cette requête
implique maitenant beaucoup MOINS que 400 000
enregistrement, probablement
100 000, non (mon estimé est basé sur des hypothèses un
peu farfelues, mais
également de par les chiffres que tu avances: 100k =
400k * ( 170 /
(18*0.5) ) ^0.5) ?
Utiliser S1 ( et S2 si applicable) au lieu des tables
originales, avec une
syntaxe voisine de la première requête, sans sa condition
WHERE maintenant
inutile, devrait alors redonner un temps d'exécution
d'une dizaine de
secondes (deux fois moins long que la requête UNION),
voire mieux (surtout
si les requêtes S1 et S2 retournent en deça de 100k-
enregistrements).
Si tu utilises MS SQL Server, tu peux faire remonter le
critère du genre:
champ=constante
DANS la clause ON appropriée du join, cela aura le même
effet. Avec Jet, on
ne peut pas, car Jet repasse derrière nous et redescend
ce critère dans le
WHERE, à moins de procéder par requêtes cascadées, comme
proposé, ou par
tables virtuelles (ce qui est la même chose, dans le
fond).
Espérant être utile,
Vanderghast, Access MVP
-----Message d'origine-----
Salut,
La raison du problème semble toute simple. La jointure
est effectuée AVANT
le where. Donc, il y a comparaisons entre plusieurs
champs, "l'explosion" du
join (une possibilité de 400 000 au carré, j'apelle
cela une explosion)
est emmagasinée temporairement, et de cette explosion,
établie, on ne
conserve, par sélection de critère WHERE, que quelques
individus. Ressources
mal utilisées!
Il serait plus astucieux, dans ce cas, de faire le
critère AVANT la
jointure:
SELECT * FROM makt WHERE maktx LIKE [Critere]
dans une requête, S1, pareil pour mfrpn LIKE [Critere],
dans une requête
S2 (ou la même requête S1, si c'est de la même table).
Cette requête
implique maitenant beaucoup MOINS que 400 000
enregistrement, probablement
100 000, non (mon estimé est basé sur des hypothèses un
peu farfelues, mais
également de par les chiffres que tu avances: 100k =
400k * ( 170 /
(18*0.5) ) ^0.5) ?
Utiliser S1 ( et S2 si applicable) au lieu des tables
originales, avec une
syntaxe voisine de la première requête, sans sa condition
WHERE maintenant
inutile, devrait alors redonner un temps d'exécution
d'une dizaine de
secondes (deux fois moins long que la requête UNION),
voire mieux (surtout
si les requêtes S1 et S2 retournent en deça de 100k-
enregistrements).
Si tu utilises MS SQL Server, tu peux faire remonter le
critère du genre:
champ=constante
DANS la clause ON appropriée du join, cela aura le même
effet. Avec Jet, on
ne peut pas, car Jet repasse derrière nous et redescend
ce critère dans le
WHERE, à moins de procéder par requêtes cascadées, comme
proposé, ou par
tables virtuelles (ce qui est la même chose, dans le
fond).
Espérant être utile,
Vanderghast, Access MVP
-----Message d'origine-----
Salut,
La raison du problème semble toute simple. La jointure
est effectuée AVANT
le where. Donc, il y a comparaisons entre plusieurs
champs, "l'explosion" du
join (une possibilité de 400 000 au carré, j'apelle
cela une explosion)
est emmagasinée temporairement, et de cette explosion,
établie, on ne
conserve, par sélection de critère WHERE, que quelques
individus. Ressources
mal utilisées!
Il serait plus astucieux, dans ce cas, de faire le
critère AVANT la
jointure:
SELECT * FROM makt WHERE maktx LIKE [Critere]
dans une requête, S1, pareil pour mfrpn LIKE [Critere],
dans une requête
S2 (ou la même requête S1, si c'est de la même table).
Cette requête
implique maitenant beaucoup MOINS que 400 000
enregistrement, probablement
100 000, non (mon estimé est basé sur des hypothèses un
peu farfelues, mais
également de par les chiffres que tu avances: 100k =
400k * ( 170 /
(18*0.5) ) ^0.5) ?
Utiliser S1 ( et S2 si applicable) au lieu des tables
originales, avec une
syntaxe voisine de la première requête, sans sa condition
WHERE maintenant
inutile, devrait alors redonner un temps d'exécution
d'une dizaine de
secondes (deux fois moins long que la requête UNION),
voire mieux (surtout
si les requêtes S1 et S2 retournent en deça de 100k-
enregistrements).
Si tu utilises MS SQL Server, tu peux faire remonter le
critère du genre:
champ=constante
DANS la clause ON appropriée du join, cela aura le même
effet. Avec Jet, on
ne peut pas, car Jet repasse derrière nous et redescend
ce critère dans le
WHERE, à moins de procéder par requêtes cascadées, comme
proposé, ou par
tables virtuelles (ce qui est la même chose, dans le
fond).
Espérant être utile,
Vanderghast, Access MVP
