Performance boucle sur table tempo avec identity [Résolu]

[Jean.Cri1]

Bonjour,

Dans une procedure stockée je crée une table tempo

Code :

#T(i identity(6) , champs ... )

puis je boucle sans curseur :

Code :

1
2
3
4
5
6
WHILE @i < @i_max
BEGIN
    SELECT @i = @i +1
    SELECT champs = champs FROM #T where i = @i
    traitements champs erreurs ...
END

Je me pose deux questions metaphysiques:
1-
le type identity permet il une "meilleure" (par rapport a un int simple) selection de mes champs pour sybase et le cas echéant dans quelles conditions ( update stat, deporter la table dans une proc en amont ... )
2-
Y aurait il un interet a inserer un delete de la ligne traitée en fin de boucle ? ( recherche dans une table de moins en moins grosse mais gestion delete ... pour ASE )

D'avance merci de vos réponses

[Yanika_bzh]

Que voulez vous dire par "meilleure selection" ?

Si votre table temporaire est volumineuse, il serait interessant de poser un index sur votre colonne i

bon courage

[mpeppler]

Personellement j'utiliserai un curseur sur la table tempo, plutot qu'un select individuel dans une boucle while.

Mais - si on utilise le select et la boucle il faut avoir un index sur la ou les colonne(s) de la clause where ("i" dans le cas présent) - autrement on se prend un table scan à chaque itération - pas un problème s'il y a 3 lignes dans la table, mais évidemment plus problématique si la table est plus grande :-)

Pour le delete - si il y a un index ce n'est à mon avis pas intéressant - et si il n'y a pas d'index le delete va aussi faire un table scan, donc va doubler le coût de chaque itération (même si les dernières itérations irons plus vite que les premières).

Michael

[Jean.Cri1]

"Meilleure selection" :

ASE ,dans sa gestion du type identity, mettrait il en oeuvre des mecanismes particuliers qui lui faciliterait l'acces a ces données ( j'ai déjà entendu mais jamais lu : faut mettre un identity , ca aide sybase ! ... ) ?

Curseur / boucle :

J'ai fait des essais sur mon jeu de test et la boucle est (un peu ) plus performante que le curseur.

Index :

A priori pourquoi pas ( mais je n'ai que ~500 ligne et un champs ), et a ce propos ,
- suis-je obligé de créer mon index dans une proc appelante apres avoir rempli la table ?
- tout faire dans la meme proc avec le select en dynamique aura -t-il le meme comportement que ci_dessus
- tout faire dans la meme proc avec un update stat apres la creation de l'index ( sur table remplie ) suffirait-t-il ?

Merci de vos contributions

[mpeppler]

Pour l'index - cela dépend de la version, en 15.x l'optimiseur est devenu plus "smart".

Perso j'ai tendance à forcer l'index sur les tables tempo quand je suis dans une proc et que je "sais" que c'est le bon index à utiliser:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
CREATE proc foo 
AS
SELECT id=identity(int), ... INTO #T from ...
 
CREATE INDEX ix ON #T(id)
...
declare @i int
SELECT @i = 0
 
while @i <= @i_max
begin
    SELECT ....FROM #T(index ix) where id = @i
    ....
    SELECT @i = @i + 1
end

Michael

[Jean.Cri1]

forcer l'index sur les tables tempo

Forcer un index est amha souvent un aveu d'impuissance.
Mais dans ce cas la, pour eviter les contraintes de sa prise en compte ( faire encore une nouvelle sous proc ou du sql dynamique ou ... ), ca me parait etre un bon raccourci.

Merci

[mpeppler]

D'accord sur le principe - mais la réalité c'est que quand on a beaucoups de tables tempo on n'a plus vraiment le choix...

Michael (qui a beaucoup d'experience avec les tables tempo depuis quelques annees...)

[Jean.Cri1]

Merci pour le retour d'experience.

Si quelqu'un a des infos sur l'optimiseur et les champs identity non indexés, je suis preneur ( meme pour infirmer la legende urbaine que j'ai colportée plus haut ).