DISTINCT versus GROUP BY

Version imprimable

Dans le but d'optimiser la vitesse d'une query je me pose la question suivante
est-il plus judicieux d'utiliser distinct ou group by (d'où le titre) lorsqu'il n'y a pas d'aggrégats (SUM , MAX ...) . Un premier test réalisé avec FlameRobin (ci dessus semble me le prouver , quoique le delta memory me semble bizarre )

DES IDEES :idea: SUR LA QUESTION :question:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
 
Preparing query: SELECT NUMERO,LIGNE
FROM EXPEDITION_RF
WHERE NUMERO=8052013 AND COLIS=1
GROUP BY NUMERO,LIGNE
Prepare time: 00:00:00.
Field #01: .NUMERO Alias:NUMERO Type:INTEGER
Field #02: .LIGNE Alias:LIGNE Type:SMALLINT
PLAN (EXPEDITION_RF ORDER RDB$PRIMARY42 INDEX (RDB$PRIMARY42))
 
 
Executing...
Done.
162 fetches, 0 marks, 0 reads, 0 writes.
0 inserts, 0 updates, 0 deletes, 50 index, 0 seq.
Delta memory: 3228 bytes.
Execute time: 00:00:00.
------------------------------------------------------------------
Preparing query: SELECT DISTINCT NUMERO,LIGNE
FROM EXPEDITION_RF
WHERE NUMERO=8052013 AND COLIS=1
 
Prepare time: 00:00:00.
Field #01: EXPEDITION_RF.NUMERO Alias:NUMERO Type:INTEGER
Field #02: EXPEDITION_RF.LIGNE Alias:LIGNE Type:SMALLINT
PLAN SORT ((EXPEDITION_RF INDEX (RDB$PRIMARY42)))
 
 
Executing...
Done.
112 fetches, 2 marks, 0 reads, 2 writes.
0 inserts, 0 updates, 0 deletes, 49 index, 0 seq.
Delta memory: -1532 bytes.
Execute time: 00:00:00.

29/03/2008, 09h51
_skip

Si le but est d'éliminer les doublons, je pense que c'est distinct qui est le plus approprié, utiliser un group by pour cela me paraît incorrect.
Je pense qu'avec distinct les index pourraient servir à discriminer une partie des doublons d'entrées de jeu, alors qu'un group by aurait tendance à isoler les lignes qui correspondent à la clause where pour ensuite les regrouper.

Mais c'est qu'une supposition, je sais pas exactement comment c'est implémenté.

Pour en avoir le coeur net, il faudrait une table de donnée d'un grand volume et faire une requête pour laquelle ta clause WHERE seule concernerait 10000 enregistrements.
31/03/2008, 11h36
SergioMaster

Citation:

Envoyé par _skip

Pour en avoir le coeur net, il faudrait une table de donnée d'un grand volume et faire une requête pour laquelle ta clause WHERE seule concernerait 10000 enregistrements.

j'ai fait :? la conclusion est loin d'être evidente
léger avantage toutefois à DISTINCT en nombre de fetchs et delta mémoire
31/03/2008, 14h07
_skip

Je pense que cela dépend de tes indexs aussi. Mais je te déconseille de détourner le group by pour cet usage.
31/03/2008, 17h02
Dschub

La réponse m'intéresse aussi car je suis en train de me poser la même question.

Les résultats que j'obtiens sont aussi très similaire mais bon j'ai pas beaucoup d'enregistrement dans ma table (>1.000) donc forcément c'est pas très pertinent.

Juste une question, a-tu pensé à vider les caches d'exécution de requêtes avant chaque requête pour éviter de fausser les résultat? (Je suis en train de voir comment on fait)
01/04/2008, 07h43
SergioMaster

Citation:

Envoyé par Dschub

Juste une question, a-tu pensé à vider les caches d'exécution de requêtes avant chaque requête pour éviter de fausser les résultat? (Je suis en train de voir comment on fait)

Requêtes faites via FlameRobin avec arrêt entre chaque donc caches d'execution vidés ???

quant à la table nbrecord >10000 , bémol pour ce dernier test les champs faisaient partis d'une foreign key . Je vais faire un essai sur un ou deux champs "brut" et vous tiens au courant

@Skip oui, je pense que le 'détournement' n'est pas une trés bonne idée . En fait je suis tombé dessus par hasard en faisant de la modif d'appli