Affecter calcul à variable SQL
Calculez instantanément le résultat d’une affectation SQL de type SET @var = @var + valeur, visualisez l’impact d’un opérateur, générez un exemple de requête et révisez les bonnes pratiques de typage, précision et sécurité.
Comprendre comment affecter un calcul à une variable SQL
Dans la pratique SQL, l’expression affecter un calcul à une variable désigne le fait de stocker le résultat d’une opération dans une variable locale, souvent via les instructions SET ou SELECT. C’est un mécanisme essentiel pour écrire des procédures stockées robustes, des scripts d’administration lisibles, des calculs intermédiaires fiables et des traitements transactionnels plus faciles à maintenir. L’idée est simple : une variable reçoit une valeur initiale, puis une expression arithmétique ou logique lui est appliquée. Exemple classique : SET @montant = @montant + 25.
Ce sujet paraît élémentaire, mais il implique en réalité plusieurs dimensions techniques : le type de données de la variable, la gestion des décimales, les divisions par zéro, les effets de conversion implicite, la différence de comportement entre SET et SELECT, ainsi que l’impact de ces choix sur la qualité du code. Le calculateur ci-dessus vous aide à visualiser ce comportement sur les opérations numériques les plus courantes.
Syntaxe de base pour l’affectation d’un calcul
Dans SQL Server, on rencontre très souvent les deux formes suivantes :
- SET @x = @x + 10 : syntaxe explicite, claire et recommandée pour une seule variable.
- SELECT @x = @x + 10 : pratique dans certains scénarios, notamment lorsque plusieurs variables sont affectées dans une même instruction.
Le principe est le même : l’expression à droite de l’égalité est évaluée, puis le résultat est stocké dans la variable à gauche. Le point critique est que le résultat final dépend du type SQL choisi. Si la variable est de type INT, une partie décimale sera perdue. Si elle est de type DECIMAL, la précision sera mieux contrôlée. Si elle est en FLOAT, vous gagnerez en flexibilité mais pourrez exposer des écarts d’arrondi typiques des nombres flottants.
Exemple simple
- Déclarer une variable : DECLARE @prix DECIMAL(10,2) = 99.90;
- Appliquer une taxe : SET @prix = @prix * 1.20;
- Consommer le résultat : SELECT @prix AS prix_ttc;
Dans cet exemple, l’utilisation d’un type décimal évite les problèmes de précision qui pourraient apparaître avec un type flottant. Pour les montants financiers, le choix du type n’est jamais anodin.
Pourquoi le type de données change tout
Lorsque vous affectez un calcul à une variable SQL, l’erreur la plus fréquente consiste à choisir un type incompatible avec le besoin métier. Beaucoup de scripts de démonstration utilisent INT par simplicité, alors que des cas réels exigent souvent DECIMAL. Voici un tableau comparatif utile avec des valeurs chiffrées couramment utilisées dans SQL Server.
| Type numérique | Taille de stockage | Plage ou précision | Usage recommandé |
|---|---|---|---|
| TINYINT | 1 octet | 0 à 255 | Compteurs simples, petits états |
| SMALLINT | 2 octets | -32,768 à 32,767 | Valeurs entières modestes |
| INT | 4 octets | -2,147,483,648 à 2,147,483,647 | Calculs entiers généraux |
| BIGINT | 8 octets | -9,223,372,036,854,775,808 à 9,223,372,036,854,775,807 | Très grands volumes, identifiants massifs |
| DECIMAL(p,s) | 5 à 17 octets | Jusqu’à 38 chiffres de précision | Finance, ratios, calculs exacts |
| FLOAT | 4 ou 8 octets | Précision approximative | Mesures scientifiques, calculs non financiers |
Les statistiques de plage et de stockage ci-dessus montrent une réalité fondamentale : choisir INT pour un calcul de remise ou de TVA peut tronquer une partie importante du résultat. À l’inverse, choisir FLOAT pour des sommes monétaires peut introduire des différences de quelques centièmes qui deviennent problématiques à grande échelle.
Tableau de précision utile pour DECIMAL
Le type DECIMAL est souvent le plus sûr pour les affectations de calcul. Son stockage dépend de la précision déclarée.
| Précision DECIMAL | Stockage | Exemple | Cas d’usage |
|---|---|---|---|
| 1 à 9 | 5 octets | DECIMAL(9,2) | Prix simples, petites mesures |
| 10 à 19 | 9 octets | DECIMAL(18,4) | Comptabilité, taux, conversions |
| 20 à 28 | 13 octets | DECIMAL(28,8) | Calculs analytiques détaillés |
| 29 à 38 | 17 octets | DECIMAL(38,10) | Scénarios de très haute précision |
SET ou SELECT pour affecter une variable ?
Le débat entre SET et SELECT est récurrent. Pour un seul calcul, SET est souvent préféré parce qu’il rend l’intention plus explicite et respecte mieux les attentes de lisibilité. SELECT reste très utilisé pour affecter plusieurs variables d’un coup ou récupérer des valeurs à partir d’une requête.
- SET favorise la clarté dans les scripts unitaires.
- SELECT peut être plus compact pour les affectations multiples.
- SET aide à réduire l’ambiguïté dans les revues de code.
- SELECT demande une vigilance accrue quand plusieurs lignes peuvent être retournées.
Dans un projet mature, la cohérence d’équipe compte souvent plus que le débat théorique. Le meilleur choix est généralement celui qui diminue le risque de mauvaise interprétation et simplifie les tests.
Bonnes pratiques pour des calculs SQL fiables
1. Toujours anticiper la division par zéro
Une affectation telle que SET @ratio = @total / @compteur doit être protégée si @compteur peut valoir zéro. Utilisez par exemple NULLIF(@compteur, 0) pour neutraliser cette erreur et produire NULL au lieu d’interrompre le script.
2. Maîtriser les conversions implicites
Quand SQL convertit automatiquement un type vers un autre, le résultat n’est pas toujours celui attendu. Un INT combiné à un DECIMAL peut donner un résultat valide, mais la précision finale dépend du contexte. Dans les traitements sensibles, privilégiez les conversions explicites avec CAST ou CONVERT.
3. Préférer DECIMAL pour les montants financiers
Un grand principe : tout ce qui touche à la facturation, à la paie, aux remises, aux taxes ou aux commissions doit être stocké et calculé avec une précision contrôlée. Pour cela, DECIMAL reste la meilleure base.
4. Limiter les effets secondaires dans les procédures
Une variable dont la valeur est modifiée à plusieurs endroits devient difficile à auditer. Si votre procédure stockée contient de nombreuses affectations successives, ajoutez des commentaires métiers et découpez le calcul en étapes logiques.
5. Tester avec des cas extrêmes
Les meilleurs scripts SQL ne sont pas seulement exacts sur des données moyennes. Ils doivent aussi résister aux valeurs nulles, négatives, énormes, minimales et aux paramètres inattendus. Un calculateur comme celui de cette page est utile pour vérifier rapidement les comportements avant intégration dans un script plus large.
Exemples concrets d’affectation de calcul
Calcul d’un total de commande
Supposons qu’un panier contienne un sous-total et qu’une remise doive être appliquée. Vous pouvez procéder ainsi :
- Déclarer @sous_total et @remise.
- Calculer @net = @sous_total – @remise.
- Calculer ensuite la taxe sur @net.
Calcul d’un pourcentage
Un autre cas classique est la transformation d’une part relative en pourcentage : SET @pct = (@part * 100.0) / NULLIF(@total, 0). La présence de 100.0 au lieu de 100 force souvent un calcul décimal plus approprié.
Compteur incrémental
Dans des scripts d’administration ou des boucles contrôlées, il est courant d’écrire SET @i = @i + 1. Ce modèle paraît trivial, mais il illustre parfaitement l’idée d’affecter le résultat d’un calcul à la même variable.
Erreurs fréquentes à éviter
- Utiliser INT alors qu’un résultat décimal est nécessaire.
- Oublier de traiter la division par zéro.
- Multiplier les affectations dans tous les sens sans documentation.
- Confondre exactitude de DECIMAL et approximation de FLOAT.
- Faire confiance aux conversions implicites sans test unitaire.
- Écrire des expressions longues sans parenthèses explicites.
Conseil d’expert : si la valeur calculée est destinée à un affichage financier, conservez une précision de calcul suffisante en base, puis formatez seulement au moment de la restitution. Arrondir trop tôt dans le flux de traitement peut provoquer des écarts cumulés.
Ressources de référence
Pour compléter votre maîtrise des calculs et des variables SQL, consultez aussi des ressources académiques et institutionnelles :
- Carnegie Mellon University Database Group
- UC Berkeley CS186 Introduction to Database Systems
- NIST – standards and guidance for data quality and information systems
Conclusion
Savoir affecter un calcul à une variable SQL n’est pas simplement une question de syntaxe. C’est un point d’appui pour écrire un code fiable, explicite et durable. Le bon développeur SQL pense toujours à la précision numérique, au type de données, à la lisibilité et aux scénarios limites. En pratique, si vous retenez trois règles, retenez celles-ci : choisissez le bon type, explicitez les conversions critiques, et testez vos calculs avec des cas réels et extrêmes. Le calculateur de cette page vous offre un moyen rapide de valider une logique d’affectation avant de l’intégrer dans une procédure stockée, un script de migration ou un traitement de reporting.