> Tech > Un peu de code pour terminer

Un peu de code pour terminer

Tech - Par Renaud ROSSET - Publié le 24 juin 2010
email

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 Sécurité IA et IoT

Guide de Sécurité IA et IoT

Compte tenu de l'ampleur des changements que l'IA est susceptible d'entraîner, les organisations doivent élaborer une stratégie pour se préparer à adopter et à sécuriser l'IA. Découvrez dans ce Livre blanc Kaspersky quatre stratégies efficaces pour sécuriser l'IA et l'IoT.

Tech - Par Renaud ROSSET - Publié le 24 juin 2010