Comment arrondir (UP/DOWN) dans SQL Server

On nous a appris à arrondir les nombres depuis que nous sommes enfants. Lorsque vous arrondirez 1,15 au dixième le plus proche, sera-ce 1,2 ou 1,1 ? L'utilisation de la fonction SQL ROUND pour répondre peut vous dérouter. Plus tard, vous verrez ce que je veux dire.

[sendpulse-form id="12010″]

Voici une autre question. Quelle est la somme de 1 + 1 ? C'est une question assez stupide. C'est pour les enfants qui apprennent les mathématiques pour la première fois, pas pour nous, les adultes. Mais s'il vous plaît jeter un oeil au code ci-dessous :

-- Variables for input values
DECLARE @value1 DECIMAL(3,2) = 1.05
DECLARE @value2 DECIMAL(3,2) = 1.45
DECLARE @sum1 DECIMAL(3,2) = @value1 + @value2

-- Variables for rounded values
DECLARE @roundedValue1 TINYINT = ROUND(@value1,0)
DECLARE @roundedvalue2 TINYINT = ROUND(@value2,0)
DECLARE @sum2 TINYINT = ROUND(@sum1,0)

-- Surprise!
SELECT 'sum of ' + CAST(@value1 AS VARCHAR(4)) + ' + ' + CAST(@value2 AS VARCHAR(4)) AS Q1,  @sum1 AS Sum1
SELECT 'sum of ' + CAST(@roundedValue1 AS VARCHAR(4)) + ' + ' + CAST(@roundedValue2 AS VARCHAR(4)) AS Q2,  @sum2 AS Sum2

Vérifiez ensuite les résultats ci-dessous :

Que s'est-il passé ici ? On obtient deux valeurs avec une partie décimale. Ensuite, nous les arrondissons en utilisant SQL ROUND au nombre entier le plus proche. Leurs sommes sont également arrondies. Mais comment 1 + 1 peuvent-ils faire 3 ? !

Un pro SQL aux yeux perspicaces repérera immédiatement le problème dans le code. Mais considérez ceci :

Arrondir 2,5 au nombre entier le plus proche donne 3, et non 2.
La somme de 1 + 1 est 2.

C'est dur, n'est-ce pas ?

Voici le point. Si vous ne faites pas attention, SQL ROUND peut vous rendre fou. Cela peut également être une source d'arguments entre les développeurs et les comptables. L'un d'entre eux concerne le principe de matérialité. Les arguments peuvent devenir moches.

Que pouvez-vous faire ?

Fonction d'arrondi dans SQL Server

Non, je ne vous dis pas de transmettre ce problème au prochain développeur. Cet article vous donnera des conseils essentiels pour que vous et votre utilisateur soyez satisfaits du résultat. Certains de ces conseils peuvent également s'appliquer à l'arrondi d'un nombre sur le côté frontal de l'application ou dans les rapports.

Voyons nos 5 conseils en détail.

Fonction d'arrondi pour les nombres en SQL

Vous savez déjà comment arrondir les nombres en SQL, alors pourquoi demander ? Il ne s'agit pas de demander comment. Il s'agit de demander quand. Vous pouvez poser des questions similaires à celles ci-dessous :

Arrondissez-vous les valeurs d'entrée AVANT de faire des calculs ?
Ou calculez-vous les valeurs d'entrée, puis arrondissez-vous le résultat ?

D'autres questions peuvent se poser en fonction des calculs que vous allez effectuer.

Le point est de savoir si vous obtenez la norme ou le modèle d'arrondi des utilisateurs. Ensuite, vous pouvez utiliser ce modèle pour écrire des requêtes. Vous ne supposez pas ou ne devinez pas ce qui conduirait à un désaccord plus tard. Et s'il est utile d'inclure cette norme sous forme de note quelque part dans le rapport, faites-le.

Une autre partie de la norme est le nombre de décimales à utiliser. Que se passe-t-il si la colonne de table a un type de données de DECIMAL(10,4) ? Comment allez-vous l'arrondir à 2 décimales seulement ?

Essayez le code ci-dessous :

DECLARE @value DECIMAL(10,4)

SET @value = 8346.1556

-- This will result in 8346.16 instead of 8346.1600
SELECT CAST(ROUND(@value, 2) AS DECIMAL(10,2))

Le CAST après le ROUND n'affichera que deux décimales. Les deux zéros seront tronqués :

Comprendre Comment SQL arrondi aux décimales

Nous répondons ici à notre première question. Lorsque vous arrondirez 1,15 au dixième le plus proche, sera-ce 1,2 ou 1,1 ?

Tout d'abord, vous le vérifiez avec le type de données DECIMAL :

DECLARE @value DECIMAL(3,2)

SET @value = 1.15

SELECT @value
SELECT ROUND(@value, 1)  -- This will result in 1.2 or 1.20

Le résultat du code ci-dessus est 1.20 ou 1.2 :

Mais que se passe-t-il si le type de données est un FLOAT ? Essayons de le changer.

DECLARE @value FLOAT

SET @value = 1.15

SELECT @value
SELECT ROUND(@value, 1)  -- This will result to 1.1

Quel est le résultat? C'est 1.1. Voyez par vous-même :

Ce n'est pas que je veuille vous donner plus de doutes. Cependant, vous devez savoir que ces types de données, bien qu'ils soient tous deux utilisés pour les nombres, ne sont pas créés égaux .

FLOAT et REAL sont des nombres approximatifs, non recommandés pour l'arrondi, pas même pour les vérifications d'égalité dans une clause WHERE.
DECIMAL et NUMERIC ont une précision et une échelle fixes, et nous les appelons des nombres exacts. Par conséquent, lorsque nous arrondissons 1,15 au dixième le plus proche, la bonne réponse est 1,2.
Les nombres entiers sont également des nombres exacts. Ils sont sûrs pour arrondir des chiffres entiers.

Le dilemme commence dès la conception de la table. Vous voudrez peut-être faire quelque chose à propos des colonnes FLOAT ou REAL qui seront arrondies quelque part.

3. Utilisez SQL ROUND sur la même source de données pour plus de cohérence

Supposons que vous deviez créer plusieurs rapports sur les revenus pour afficher différents détails :le résumé, la répartition détaillée par type et la répartition détaillée par source. Ces trois rapports traiteront les cents ou les parties décimales comme non significatifs. Il est donc inévitable d'arrondir les valeurs à des nombres entiers.

Pour obtenir des résultats cohérents dans les trois rapports, appliquez ce qui suit :

SELECT à partir des mêmes tables de base pour s'assurer que les totaux des détails sont cohérents avec le résumé.
Utilisez le même modèle pour arrondir (point 1 ci-dessus)

Voulez-vous que vos utilisateurs soient satisfaits de ces rapports sur les revenus ? Soyez cohérent sur où et comment vous obtenez vos chiffres.

4. SQL ÉTAGE ou PLAFOND VS ROND

Il peut y avoir des cas où vous devez arrondir au nombre entier supérieur ou inférieur. Dans ce cas, CEILING() ou FLOOR() est le choix approprié au lieu de ROUND()

CEILING() arrondit une valeur à l'entier suivant :

SELECT CEILING(1);   -- returns 1 
SELECT CEILING(1.6);  -- returns 2
SELECT CEILING(1.4);  -- returns 2

Pendant ce temps, FLOOR() arrondit à l'inférieur :

SELECT FLOOR(1);   -- returns 1 
SELECT FLOOR(2.1); -- returns 2 
SELECT FLOOR(2.9); -- returns 2

5. Testez les résultats avec vos utilisateurs

Après avoir terminé toutes les requêtes et la conception du rapport, la dernière partie consiste à vérifier votre travail avec les utilisateurs. Nous pouvons faire des erreurs, peu importe à quel point nous sommes bons ou à quel point nous travaillons dur. Parfois, nous avons besoin de quelques itérations supplémentaires pour bien faire les choses.

Vos utilisateurs disposeront de scénarios de test qui garantiront l'exactitude des rapports. Ou elle peut avoir un fichier Excel fait manuellement pour comparer votre travail au leur. Dans tous les cas, travaillez avec eux pour un meilleur système. Vous serez content de l'avoir fait.

Conclusion

Travailler avec SQL ROUND peut parfois être difficile. Cependant, les conseils présentés ici prouvent que vous pouvez gagner contre ces obstacles. Qu'avez-vous appris ?

Demandez la norme ou le modèle d'arrondi à vos utilisateurs.
Connaissez le type de données que vous utilisez.
Utilisez ROUND sur la même source de données pour plus de cohérence.
Parfois, FLOOR ou CEILING peut être plus approprié que ROUND.
Enfin, testez vos résultats auprès de vos utilisateurs.

Ce message est-il utile ? Si c'est pour vous, d'autres peuvent en avoir besoin aussi. Veuillez partager ce message sur vos réseaux sociaux préférés.

Comment arrondir (UP/DOWN) dans SQL Server - 5 conseils utiles