Performance boucle sur table tempo avec identity

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

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

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

"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

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

Citation:

---

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

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...)

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 ).