Comment éviter l'erreur «diviser par zéro» dans SQL?

J'ai ce message d'erreur:

Msg 8134, niveau 16, état 1, ligne 1 Diviser par zéro erreur rencontrée.

Quelle est la meilleure façon d'écrire du code SQL pour que je ne revoie plus jamais ce message d'erreur?

Je pourrais effectuer l'une des opérations suivantes:

• Ajouter une clause where pour que mon diviseur ne soit jamais nul

Ou

• Je pourrais ajouter un énoncé de cas, afin qu'il y ait un traitement spécial pour zéro.

Est-ce la meilleure façon d'utiliser une NULLIFclause?

Y a-t-il une meilleure façon, ou comment cela peut-il être appliqué?

Afin d'éviter une erreur de "Division par zéro" nous l'avons programmée comme ceci:

Select Case when divisor=0 then null
Else dividend / divisor
End ,,,

Mais voici une manière beaucoup plus agréable de le faire:

Select dividend / NULLIF(divisor, 0) ...

Maintenant, le seul problème est de se souvenir du bit NullIf, si j'utilise la touche "/".

Dans le cas où vous souhaitez retourner zéro, dans le cas où une déviation zéro se produirait, vous pouvez utiliser:

SELECT COALESCE(dividend / NULLIF(divisor,0), 0) FROM sometable

Pour chaque diviseur qui est nul, vous obtiendrez un zéro dans le jeu de résultats.

Cela semblait être la meilleure solution pour ma situation lorsque j'essayais de résoudre le problème de la division par zéro, ce qui se produit dans mes données.

Supposons que vous vouliez calculer les ratios hommes-femmes pour divers clubs scolaires, mais vous découvrez que la requête suivante échoue et génère une erreur de division par zéro lorsqu'il essaie de calculer le ratio pour le Lord of the Rings Club, qui n'a pas de femmes :

SELECT club_id, males, females, males/females AS ratio
  FROM school_clubs;

Vous pouvez utiliser la fonction NULLIFpour éviter la division par zéro. NULLIFcompare deux expressions et renvoie null si elles sont égales ou la première expression sinon.

Réécrivez la requête comme suit:

SELECT club_id, males, females, males/NULLIF(females, 0) AS ratio
  FROM school_clubs;

Tout nombre divisé par NULLdonne NULLet aucune erreur n'est générée.

Vous pouvez également le faire au début de la requête:

SET ARITHABORT OFF 
SET ANSI_WARNINGS OFF

Donc, si vous avez quelque chose comme 100/0ça, cela retournera NULL. Je n'ai fait cela que pour des requêtes simples, donc je ne sais pas comment cela affectera les plus longues / complexes.

Vous pouvez au moins empêcher la requête de se rompre avec une erreur et retourner NULLs'il y a une division par zéro:

SELECT a / NULLIF(b, 0) FROM t 

Cependant, je ne convertirais JAMAIS cela en zéro avec coalescecomme cela est montré dans cette autre réponse qui a reçu de nombreuses augmentations. C'est complètement faux au sens mathématique, et c'est même dangereux car votre application retournera probablement des résultats faux et trompeurs.

EDIT: Je reçois beaucoup de downvotes récemment ... alors j'ai pensé que j'ajouterais simplement que cette réponse a été écrite avant que la question ne subisse sa dernière modification, où le retour de null était mis en surbrillance en option .. .qui semble très acceptable. Une partie de ma réponse s'adressait à des préoccupations comme celle d'Edwardo, dans les commentaires, qui semblait préconiser le retour d'un 0. C'est le cas contre lequel je me plaignais.

RÉPONSE: Je pense qu'il y a un problème sous-jacent ici, c'est que la division par 0 n'est pas légale. C'est une indication que quelque chose ne va pas fondamentalement. Si vous divisez par zéro, vous essayez de faire quelque chose qui n'a pas de sens mathématique, donc aucune réponse numérique que vous pouvez obtenir ne sera valide. (L'utilisation de null dans ce cas est raisonnable, car ce n'est pas une valeur qui sera utilisée dans des calculs mathématiques ultérieurs).

Edwardo demande donc dans les commentaires "et si l'utilisateur met un 0?", Et il préconise que ce soit correct d'obtenir un 0 en retour. Si l'utilisateur met zéro dans le montant et que vous voulez que 0 soit renvoyé lorsqu'il le fait, alors vous devez mettre du code au niveau des règles métier pour attraper cette valeur et retourner 0 ... pas de cas particulier où la division par 0 = 0.

C'est une différence subtile, mais c'est important ... parce que la prochaine fois que quelqu'un appelle votre fonction et s'attend à ce qu'elle fasse la bonne chose, et elle fait quelque chose de génial qui n'est pas mathématiquement correct, mais qui gère simplement le cas de bord particulier, il a un bonne chance de mordre quelqu'un plus tard. Vous ne divisez pas vraiment par 0 ... vous retournez simplement une mauvaise réponse à une mauvaise question.

Imaginez que je code quelque chose et je le foirais. Je devrais lire une valeur d'échelle de mesure de rayonnement, mais dans un cas de bord étrange que je n'avais pas prévu, j'ai lu 0. Je laisse ensuite ma valeur dans votre fonction ... vous me renvoyez un 0! Vive, pas de rayonnement! Sauf que c'est vraiment là et c'est juste que je passais dans une mauvaise valeur ... mais je n'en ai aucune idée. Je veux que la division lance l'erreur parce que c'est le drapeau que quelque chose ne va pas.

SELECT Dividend / ISNULL(NULLIF(Divisor,0), 1) AS Result from table

En attrapant le zéro avec un nullif (), puis le null résultant avec un isnull (), vous pouvez contourner votre division par une erreur de zéro.

Remplacer "diviser par zéro" par zéro est controversé - mais ce n'est pas non plus la seule option. Dans certains cas, le remplacement par 1 est (raisonnablement) approprié. Je me retrouve souvent à utiliser

 ISNULL(Numerator/NULLIF(Divisor,0),1)

quand je regarde les changements dans les scores / comptes, et que je veux par défaut à 1 si je n'ai pas de données. Par exemple

NewScore = OldScore *  ISNULL(NewSampleScore/NULLIF(OldSampleScore,0),1) 

Plus souvent qu'autrement, j'ai en fait calculé ce rapport ailleurs (notamment parce qu'il peut générer des facteurs d'ajustement très importants pour les petits dénominateurs. Dans ce cas, je contrôlerais normalement que OldSampleScore est supérieur à un seuil; ce qui exclut alors zéro Mais parfois, le «hack» est approprié.

J'ai écrit une fonction il y a quelque temps pour la gérer pour mes procédures stockées :

print 'Creating safeDivide Stored Proc ...'
go

if exists (select * from dbo.sysobjects where  name = 'safeDivide') drop function safeDivide;
go

create function dbo.safeDivide( @Numerator decimal(38,19), @divisor decimal(39,19))
   returns decimal(38,19)
begin
 -- **************************************************************************
 --  Procedure: safeDivide()
 --     Author: Ron Savage, Central, ex: 1282
 --       Date: 06/22/2004
 --
 --  Description:
 --  This function divides the first argument by the second argument after
 --  checking for NULL or 0 divisors to avoid "divide by zero" errors.
 -- Change History:
 --
 -- Date        Init. Description
 -- 05/14/2009  RS    Updated to handle really freaking big numbers, just in
 --                   case. :-)
 -- 05/14/2009  RS    Updated to handle negative divisors.
 -- **************************************************************************
   declare @p_product    decimal(38,19);

   select @p_product = null;

   if ( @divisor is not null and @divisor <> 0 and @Numerator is not null )
      select @p_product = @Numerator / @divisor;

   return(@p_product)
end
go

1. Ajouter une contrainte CHECK qui force Divisorà être différent de zéro
2. Ajoutez un validateur au formulaire afin que l'utilisateur ne puisse pas saisir de valeurs nulles dans ce champ.

Pour la mise à jour des SQL:

update Table1 set Col1 = Col2 / ISNULL(NULLIF(Col3,0),1)

Il n'y a pas de réglage global magique «désactiver la division par 0 exception». L'opération doit renvoyer, car la signification mathématique de x / 0 est différente de la signification NULL, elle ne peut donc pas retourner NULL. Je suppose que vous prenez soin de l'évidence et que vos requêtes ont des conditions qui devraient éliminer les enregistrements avec le diviseur 0 et ne jamais évaluer la division. Le «piège» habituel est que la plupart des développeurs s'attendent à ce que SQL se comporte comme des langages procéduraux et offre un court-circuit à l'opérateur logique, mais ce n'est PAS le cas . Je vous recommande de lire cet article: http://www.sqlmag.com/Articles/ArticleID/9148/pg/2/2.html

Voici une situation où vous pouvez diviser par zéro. La règle commerciale est que pour calculer les rotations des stocks, vous prenez le coût des marchandises vendues pour une période, l'annualisez. Une fois que vous avez le nombre annualisé, vous divisez par l'inventaire moyen pour la période.

Je cherche à calculer le nombre de tours d'inventaire qui se produisent dans une période de trois mois. J'ai calculé que le coût des marchandises a été vendu au cours de la période de trois mois de 1 000 $. Le taux de vente annuel est de 4 000 $ (1 000 $ / 3) * 12. L'inventaire de début est 0. L'inventaire de fin est 0. Mon inventaire moyen est maintenant 0. J'ai des ventes de 4000 $ par an et aucun inventaire. Cela donne un nombre infini de tours. Cela signifie que tout mon inventaire est converti et acheté par les clients.

Il s'agit d'une règle commerciale sur la façon de calculer les rotations des stocks.

CREATE FUNCTION dbo.Divide(@Numerator Real, @Denominator Real)
RETURNS Real AS
/*
Purpose:      Handle Division by Zero errors
Description:  User Defined Scalar Function
Parameter(s): @Numerator and @Denominator

Test it:

SELECT 'Numerator = 0' Division, dbo.fn_CORP_Divide(0,16) Results
UNION ALL
SELECT 'Denominator = 0', dbo.fn_CORP_Divide(16,0)
UNION ALL
SELECT 'Numerator is NULL', dbo.fn_CORP_Divide(NULL,16)
UNION ALL
SELECT 'Denominator is NULL', dbo.fn_CORP_Divide(16,NULL)
UNION ALL
SELECT 'Numerator & Denominator is NULL', dbo.fn_CORP_Divide(NULL,NULL)
UNION ALL
SELECT 'Numerator & Denominator = 0', dbo.fn_CORP_Divide(0,0)
UNION ALL
SELECT '16 / 4', dbo.fn_CORP_Divide(16,4)
UNION ALL
SELECT '16 / 3', dbo.fn_CORP_Divide(16,3)

*/
BEGIN
    RETURN
        CASE WHEN @Denominator = 0 THEN
            NULL
        ELSE
            @Numerator / @Denominator
        END
END
GO

Filtrez les données en utilisant une clause where afin de ne pas obtenir de valeurs 0.

Parfois, 0 peut ne pas être approprié, mais parfois 1 n'est pas non plus approprié. Parfois, un saut de 0 à 100 000 000 décrit comme un changement de 1 ou 100% peut également être trompeur. 100 000 000 pour cent pourraient être appropriés dans ce scénario. Cela dépend du type de conclusions que vous avez l'intention de tirer en fonction des pourcentages ou des ratios.

Par exemple, un article à très petite vente passant de 2 à 4 vendus et un article à très grande vente passant de 1 000 000 à 2 000 000 vendus pourraient signifier des choses très différentes pour un analyste ou pour la direction, mais ils se présenteraient tous les deux à 100% ou 1. changement.

Il peut être plus facile d'isoler les valeurs NULL que de parcourir un groupe de lignes de 0% ou 100% mélangées à des données légitimes. Souvent, un 0 dans le dénominateur peut indiquer une erreur ou une valeur manquante, et vous ne voudrez peut-être pas simplement remplir une valeur arbitraire juste pour rendre votre ensemble de données bien rangé.

CASE
     WHEN [Denominator] = 0
     THEN NULL --or any value or sub case
     ELSE [Numerator]/[Denominator]
END as DivisionProblem

Voici comment je l'ai corrigé:

IIF (ValueA! = 0, Total / ValueA, 0)

Il peut être encapsulé dans une mise à jour:

SET Pct = IIF (ValueA! = 0, Total / ValueA, 0)

Ou dans une sélection:

SELECT IIF (ValueA! = 0, Total / ValueA, 0) AS Pct FROM Tablename;

Pensées?

Vous pouvez gérer l'erreur de manière appropriée lorsqu'elle se propage au programme appelant (ou l'ignorer si c'est ce que vous voulez). En C #, toutes les erreurs qui se produisent en SQL lèveront une exception que je pourrai intercepter puis gérer dans mon code, comme toute autre erreur.

Je suis d'accord avec Beska en ce que vous ne voulez pas cacher l'erreur. Vous n'avez peut-être pas affaire à un réacteur nucléaire, mais cacher des erreurs en général est une mauvaise pratique de programmation. C'est l'une des raisons pour lesquelles la plupart des langages de programmation modernes implémentent une gestion structurée des exceptions pour découpler la valeur de retour réelle avec un code d'erreur / d'état. Cela est particulièrement vrai lorsque vous faites des mathématiques. Le plus gros problème est que vous ne pouvez pas distinguer entre un 0 correctement calculé renvoyé ou un 0 à la suite d'une erreur. Au lieu de cela, toute valeur renvoyée est la valeur calculée et si quelque chose se passe mal, une exception est levée. Cela variera bien sûr en fonction de la façon dont vous accédez à la base de données et de la langue que vous utilisez, mais vous devriez toujours pouvoir recevoir un message d'erreur que vous pouvez traiter.

try
{
    Database.ComputePercentage();
}
catch (SqlException e)
{
    // now you can handle the exception or at least log that the exception was thrown if you choose not to handle it
    // Exception Details: System.Data.SqlClient.SqlException: Divide by zero error encountered.
}

Utilisez NULLIF(exp,0)mais de cette façon -NULLIF(ISNULL(exp,0),0)

NULLIF(exp,0)casse si exp est nullmais NULLIF(ISNULL(exp,0),0)ne cassera pas