Discussion :

[Dionisos]

est il plus rapide de faire un delete et ensuite un insert plutot qu'un update
car je lance une procedure stockée qui insere des champs calculés dans une table par le biais d'un update, mais le probleme est que c'est beaucoup trop lent..

[Xo]

Salut, et bienvenue sur ce forum,

Si tes UPDATE sont lents, peut-être ta table est-elle mal indexée ?

Si faire un UPDATE sur un seul enregistrement est lent, alors une procédure qui ira lire ton enregistrement (même clause WHERE que le UPDATE), le supprimmer puis le re-créer avec les données adéquates (celles que tu as lu + traitement de la MAJ) pourra difficilement être plus performant !

Je ne parle pas des UPDATE sur plusieurs enregistrements, car cela n'a pas l'air d'être ton cas, mais dans une telle situation, tu auras à boucler sur tes INSERT/DELETE ...

Si tu veux plus d'infos, précise :
- ton SGBD,
- la structure de ta table (champs significatifs),
- le type de requête que tu fais dessus,
- le nombre approximatif d'enregistrements,
- toute info supplémentaire que tu pourrais juger utile ...

@+

[Dionisos]

en fait je suis sur sqlserver 2000 et ma table en question contient environ 200 champs dont une disaine que j'ai rajoute et qui sont des champs calcules comme des moyenne etc.. Cette table en question est une table temporaire qui me sert de table tampon pour mettre a jour une autre table
grace a un delete/insert.
Par consequent j'insere toutes mes ligne dans cette table (environ 300000 lignes) et je lance ma procedure stockée qui permet de calculer les 10 champs. Dans ma procedure stockée j'update donc les 10 champs calculés sur toute mes lignes (par le biais d'un curseur)
Et donc le probleme majeur est la lenteur de l'update alors que la simple insertion de mes 300000 lignes ne dure que 15 min

[Dionisos]

une petite chose encore, j'ai des sous-requetes dans ma procedure et j'ai donc testé la rapidité en les enlevant mais cela ne change rien au niveau performance

[Xo]

200 champs pour une table, ça fait déjà beaucoup !

Au niveau du schéma, il est préférable de séparer les infos "statiques" (fixes) des infos "statistiques" (calculées) : le mieux serait donc sant doute de créer une table à part contenant la même PK que ta première table, avec la dizaine de champs de type "calculs".

Concernant la procédure, comment es-tu sûr que ce soit l'UPDATE qui est lent ? Cela pourraît être les calculs des valeurs de champs ? Disposes-tu de procédures permettant de connaître le temps d'éxecution de chaque opération ? Sous Oracle, c'est possible grâce au package sp_tim, je ne connais pas SQL Server ...

Au niveau de ton intruction UPDATE, la clause WHERE porte-elle uniquement sur la clé primaire de ta table (donc indexée par défaut je crois), ou sur autre chose ?

[Dionisos]

200 champs pour une table, ça fait déjà beaucoup !

Je trouve aussi, mais cette table est la plus grosse de l'ERP que j'utilise

Au niveau du schéma, il est préférable de séparer les infos "statiques" (fixes) des infos "statistiques" (calculées) : le mieux serait donc sant doute de créer une table à part contenant la même PK que ta première table, avec la dizaine de champs de type "calculs".

Je vais essayer cette solution, mais ma procédure était aussi faite pour réunir ses infos dans la même table entre autre

Concernant la procédure, j'ai tester avec un seul calcul et elle est aussi lente donc je pense que c'est l'update mais je ne suis pas absolument sur
Enfin, au niveau de l'intruction UPDATE, la clause WHERE porte uniquement sur la clé primaire de la table

[Xo]

Concernant la procédure, j'ai tester avec un seul calcul et elle est aussi lente donc je pense que c'est l'update mais je ne suis pas absolument sur
Enfin, au niveau de l'intruction UPDATE, la clause WHERE porte uniquement sur la clé primaire de la table

As-tu trouvé un mouchard pour la mesure du temps ?

Pas de Trigger BEFORE/AFTER UPDATE sur ta table ?

Je n'ai pas d'autres idées ...