Le code Transact SQL des routines est aussi un point dur de la perte de vélocité des traitements. Pour les fonctions utilisateurs (UDF), évitez les fonctions tables. Les tables ainsi produites ne peuvent être optimisées. Parce qu'elles sont susceptibles d'être lancées sur des dizaines de milliers de lignes, le code
Un peu de code pour terminer
des fonctions scalaires doit être étudié à la loupe. On prendra soin par exemple d’éliminer tous les effets de bord avant de commencer à dérouler l’algorithme. Cela permettra de s’affranchir de lancer du code en pure perte.
Démonstration :
CREATE FUNCTION F_PIVOT (@data VARCHAR(8000), @pivot int)
RETURNS VARCHAR(8000)
AS
RETURN SUBSTRING(@data, @pivot+1, LEN(@data)-@pivot) +
SUBSTRING(@data, @pivot, 1) +
SUBSTRING(@data, 1, @pivot-1)
END
Voici une fonction permettant de pivoter deux parties d’une chaîne par rapport à un caractère de position donné. Par exemple F_PIVOT(‘aperçurent’, 7) donne ‘entraperçu’… Étonnant non ? Mais cette fonction oblige à dérouler le code lorsque les paramètres sont nuls ou inopérants. Appliquées à des tables composées de milliers de lignes, de telles fonctions perdent du temps, notamment s’il y a un fort taux de NULL, chaînes vides…
Voici cette même fonction récrite pour améliorer ses temps de réponse :
CREATE FUNCTION F_PIVOT (@data VARCHAR(8000), @pivot int) RETURNS VARCHAR(8000) AS BEGIN — premier effet de bord: un des paramètres est manquant IF @data IS NULL OR @pivot IS NULL RETURN NULL —
second effet de bord, la chaîne est vide IF @data = » RETURN » — troisième effet de bord, le pivot est supérieur à la longueur de chaîne IF @pivot > LEN(@data) RETURN @pivot — quatrième effet de bord, le pivot est négatif IF @pivot <= 0 RETURN @pivot — cas général RETURN SUBSTRING(@data, @pivot+1, LEN(@data)-@pivot) + SUBSTRING(@data, @pivot, 1) + SUBSTRING(@data, 1, @pivot-1) END GO On pourra prévoir de même pour certaines procédures.
Au fait, pour les procédures : bannissez les curseurs. Il est très rare qu’un curseur soit plus rapide qu’une requête… Et dans leur très grande majorité, ces derniers peuvent être remplacés par des requêtes ou un code moins agressif. Un curseur interdit toute optimisation, tant est si bien qu’une requête même complexe va très souvent beaucoup plus vite qu’un curseur de quelques lignes. Enfin, en matière de transaction, choisissez le bon niveau d’isolation (le plus faible possible) et surtout le code le plus court afin que la durée de la transaction soit la plus petite. Peut être n’avez vous pas besoin de tout transactionner !
Téléchargez cette ressource
Guide de Threat Intelligence contextuelle
Ce guide facilitera l’adoption d’une Threat Intelligence - renseignement sur les cybermenaces, cyberintelligence - adaptée au "contexte", il fournit des indicateurs de performance clés (KPI) pour progresser d' une posture défensive vers une approche centrée sur l’anticipation stratégique
Les articles les plus consultés
Les plus consultés sur iTPro.fr
- Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
- À l’aube de 2026, le SaaS entre dans une nouvelle phase
- Face à l’urgence écologique, l’IT doit faire sa révolution
- IoT et cybersécurité : les bases que chaque décideur doit maîtriser
Articles les + lus
CES 2026 : l’IA physique et la robotique redéfinissent le futur
Les 3 prédictions 2026 pour Java
Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
Face à l’urgence écologique, l’IT doit faire sa révolution
D’ici 2030, jusqu’à 90 % du code pourrait être écrit par l’IA, pour les jeunes développeurs, l’aventure ne fait que commencer
À la une de la chaîne Tech
- CES 2026 : l’IA physique et la robotique redéfinissent le futur
- Les 3 prédictions 2026 pour Java
- Semi-conducteurs : comment l’Irlande veut contribuer à atténuer la pénurie mondiale de puces
- Face à l’urgence écologique, l’IT doit faire sa révolution
- D’ici 2030, jusqu’à 90 % du code pourrait être écrit par l’IA, pour les jeunes développeurs, l’aventure ne fait que commencer
