Come evitare l'errore "divide per zero" in SQL?

Ho questo messaggio di errore:

Messaggio 8134, livello 16, stato 1, riga 1 Si è verificato un errore di divisione per zero.

Qual è il modo migliore per scrivere il codice SQL in modo che non vedrò mai più questo messaggio di errore?

Potrei fare una delle seguenti operazioni:

• Aggiungi una clausola where in modo che il mio divisore non sia mai zero

O

• Potrei aggiungere una dichiarazione del caso, in modo che ci sia un trattamento speciale per zero.

È il modo migliore di usare una NULLIFclausola?

Esiste un modo migliore o come può essere applicato?

Per evitare un errore "Divisione per zero" lo abbiamo programmato in questo modo:

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

Ma ecco un modo molto più bello di farlo:

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

Ora l'unico problema è ricordare il bit NullIf, se uso il tasto "/".

Nel caso in cui si desideri restituire zero, nel caso in cui si verifichi una devisione zero, è possibile utilizzare:

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

Per ogni divisore che è zero, otterrai uno zero nel set di risultati.

Questa sembrava essere la soluzione migliore per la mia situazione quando cercavo di affrontare la divisione per zero, cosa che succede nei miei dati.

Supponiamo di voler calcolare i rapporti maschio-femmina per i vari club scolastici, ma scopri che la query seguente non riesce e genera un errore di divisione per zero quando tenta di calcolare il rapporto per il Lord of the Rings Club, che non ha donne :

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

È possibile utilizzare la funzione NULLIFper evitare la divisione per zero. NULLIFconfronta due espressioni e restituisce null se sono uguali o altrimenti la prima espressione.

Riscrivi la query come:

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

Qualsiasi numero diviso per NULLdà NULLe non viene generato alcun errore.

Puoi anche farlo all'inizio della query:

SET ARITHABORT OFF 
SET ANSI_WARNINGS OFF

Quindi se hai qualcosa del genere 100/0restituirà NULL. L'ho fatto solo per query semplici, quindi non so come influenzerà quelle più lunghe / complesse.

È possibile almeno interrompere l'interruzione della query con un errore e restituire NULLse esiste una divisione per zero:

SELECT a / NULLIF(b, 0) FROM t 

Tuttavia, non lo trasformerei MAI in Zero con coalescecome è mostrato in quell'altra risposta che ha ottenuto molti voti. Questo è completamente sbagliato in senso matematico ed è persino pericoloso poiché l'applicazione probabilmente restituirà risultati errati e fuorvianti.

EDIT: Recentemente sto ricevendo molti voti negativi su questo ... quindi ho pensato di aggiungere solo una nota che questa risposta è stata scritta prima che la domanda subisse la sua modifica più recente, in cui il ritorno di null era evidenziato come un'opzione .. .che sembra molto accettabile. Una parte della mia risposta è stata indirizzata a preoccupazioni come quella di Edwardo, nei commenti, che sembravano sostenere la restituzione di uno 0. Questo è il caso contro cui mi sono opposto.

RISPOSTA: Penso che ci sia un problema di fondo qui, che è che la divisione per 0 non è legale. È un'indicazione che qualcosa è fondamentalmente sbagliato. Se stai dividendo per zero, stai provando a fare qualcosa che non ha senso matematicamente, quindi nessuna risposta numerica che puoi ottenere sarà valida. (L'uso di null in questo caso è ragionevole, in quanto non è un valore che verrà utilizzato nei calcoli matematici successivi).

Quindi Edwardo nei commenti "cosa succede se l'utente inserisce uno 0?", E sostiene che dovrebbe essere corretto ottenere uno 0 in cambio. Se l'utente inserisce zero nell'importo e si desidera che venga restituito 0 quando lo fanno, è necessario inserire il codice a livello delle regole aziendali per acquisire quel valore e restituire 0 ... non avere un caso speciale in cui la divisione per 0 = 0.

Questa è una differenza sottile, ma è importante ... perché la prossima volta che qualcuno chiama la tua funzione e si aspetta che faccia la cosa giusta, e fa qualcosa di funky che non è matematicamente corretto, ma gestisce solo il caso limite particolare che ha un buone possibilità di mordere qualcuno più tardi. Non stai davvero dividendo per 0 ... stai solo restituendo una cattiva risposta a una cattiva domanda.

Immagina di codificare qualcosa e di rovinarlo. Dovrei leggere in un valore di ridimensionamento della misurazione della radiazione, ma in uno strano caso limite non ho previsto, ho letto in 0. Quindi trascino il mio valore nella tua funzione ... mi restituisci uno 0! Evviva, nessuna radiazione! Solo che è davvero lì ed è solo che stavo passando un valore negativo ... ma non ne ho idea. Voglio che la divisione lanci l'errore perché è la bandiera che qualcosa non va.

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

Catturando lo zero con un nullif (), quindi il null risultante con un isnull () è possibile aggirare la divisione per errore zero.

Sostituire "dividi per zero" con zero è controverso, ma non è nemmeno l'unica opzione. In alcuni casi la sostituzione con 1 è (ragionevolmente) appropriata. Mi trovo spesso a usare

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

quando osservo i cambiamenti nei punteggi / conteggi e desidero impostare il valore predefinito 1 se non ho dati. Per esempio

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

Più spesso, in realtà ho calcolato questo rapporto altrove (non ultimo perché può generare alcuni fattori di aggiustamento molto grandi per i denominatori bassi. In questo caso normalmente controllo su OldSampleScore è maggiore di una soglia; che quindi preclude zero Ma a volte l '"hack" è appropriato.

Ho scritto una funzione qualche tempo fa per gestirla per le mie stored procedure :

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. Aggiungi un vincolo CHECK che impone Divisordi essere diverso da zero
2. Aggiungi un validatore al modulo in modo che l'utente non possa inserire valori zero in questo campo.

Per aggiornare SQL:

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

Non esiste un'impostazione globale magica "disattiva la divisione per 0 eccezioni". L'operazione deve essere lanciata, poiché il significato matematico di x / 0 è diverso dal significato NULL, quindi non può restituire NULL. Presumo che tu ti stia occupando dell'ovvio e le tue domande hanno condizioni che dovrebbero eliminare i record con il divisore 0 e non valutare mai la divisione. Il solito 'gotcha' è che la maggior parte degli sviluppatori si aspetta che SQL si comporti come linguaggi procedurali e offra un cortocircuito logico all'operatore, ma NON lo fa . Vi consiglio di leggere questo articolo: http://www.sqlmag.com/Articles/ArticleID/9148/pg/2/2.html

Ecco una situazione in cui puoi dividere per zero. La regola aziendale è che per calcolare i turni di inventario, si prende il costo delle merci vendute per un periodo, lo si annualizza. Dopo aver ottenuto il numero annualizzato, dividi per l'inventario medio per il periodo.

Sto cercando di calcolare il numero di giri di inventario che si verificano in un periodo di tre mesi. Ho calcolato che ho un costo della merce venduto durante il periodo di tre mesi di $ 1.000. Il tasso di vendita annuale è di $ 4.000 ($ 1.000 / 3) * 12. L'inventario iniziale è 0. L'inventario finale è 0. Il mio inventario medio è ora 0. Ho un fatturato di $ 4000 all'anno e nessun inventario. Questo produce un numero infinito di turni. Ciò significa che tutto il mio inventario viene convertito e acquistato dai clienti.

Questa è una regola aziendale su come calcolare i turni di inventario.

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

Filtra i dati utilizzando una clausola where in modo da non ottenere 0 valori.

A volte, 0 potrebbe non essere appropriato, ma a volte 1 non è appropriato. A volte un salto da 0 a 100.000.000 descritto come variazione dell'1 o del 100 percento potrebbe anche essere fuorviante. Il 100.000.000 per cento potrebbe essere appropriato in quello scenario. Dipende dal tipo di conclusioni che intendi trarre in base alle percentuali o ai rapporti.

Ad esempio, un articolo di vendita molto piccolo che passa da 2-4 venduti e un articolo di vendita molto grande che passa da 1.000.000 a 2.000.000 venduti potrebbe significare cose molto diverse per un analista o per il management, ma verrebbero entrambi al 100% o 1 modificare.

Potrebbe essere più semplice isolare i valori NULL piuttosto che frugare su un mucchio di righe 0% o 100% mescolate con dati legittimi. Spesso, uno 0 nel denominatore può indicare un errore o un valore mancante e potresti non voler semplicemente inserire un valore arbitrario solo per rendere ordinato il tuo set di dati.

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

Ecco come l'ho risolto:

IIF (Valore A! = 0, Totale / Valore A, 0)

Può essere racchiuso in un aggiornamento:

SET Pct = IIF (Valore A! = 0, Totale / Valore A, 0)

O in una selezione:

SELEZIONA IIF (Valore A! = 0, Totale / Valore A, 0) AS Pct FROM Tablename;

Pensieri?

È possibile gestire l'errore in modo appropriato quando si propaga al programma chiamante (o ignorarlo se è quello che si desidera). In C # tutti gli errori che si verificano in SQL genereranno un'eccezione che posso rilevare e quindi gestire nel mio codice, proprio come qualsiasi altro errore.

Sono d'accordo con Beska in quanto non vuoi nascondere l'errore. Potresti non avere a che fare con un reattore nucleare ma nascondere errori in generale è una cattiva pratica di programmazione. Questo è uno dei motivi per cui i più moderni linguaggi di programmazione implementano la gestione strutturata delle eccezioni per disaccoppiare il valore di ritorno effettivo con un codice di errore / stato. Questo è particolarmente vero quando stai facendo matematica. Il problema più grande è che non è possibile distinguere tra 0 restituito correttamente calcolato o 0 come risultato di un errore. Invece qualsiasi valore restituito è il valore calcolato e se qualcosa va storto viene generata un'eccezione. Questo ovviamente differirà a seconda di come si accede al database e di quale lingua si sta utilizzando, ma si dovrebbe sempre essere in grado di ricevere un messaggio di errore che è possibile gestire.

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.
}

Usa NULLIF(exp,0)ma in questo modo -NULLIF(ISNULL(exp,0),0)

NULLIF(exp,0)si interrompe se exp è nullma NULLIF(ISNULL(exp,0),0)non si romperà