Як уникнути помилки "поділити на нуль" у SQL?

У мене є повідомлення про помилку:

Msg 8134, Рівень 16, стан 1, рядок 1 Розділіть на нульову помилку.

Який найкращий спосіб написати SQL-код, щоб я більше ніколи не побачив це повідомлення про помилку?

Я можу зробити щось із наступного:

• Додайте пункт де, щоб мій дільник ніколи не дорівнював нулю

Або

• Я можу додати заяву справи, щоб було спеціальне звернення до нуля.

Чи найкращий спосіб використовувати NULLIFпункт?

Чи є кращий спосіб, або як це можна застосувати?

Щоб уникнути помилки "Поділ на нуль", ми запрограмували її так:

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

Але ось набагато приємніший спосіб зробити це:

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

Тепер єдина проблема - запам'ятати біт NullIf, якщо я використовую клавішу "/".

У випадку, якщо ви хочете повернути нуль, у випадку, якщо станеться нульове відхилення, ви можете використовувати:

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

Для кожного дільника, який дорівнює нулю, ви отримаєте нуль у наборі результатів.

Це здавалося найкращим виправленням моєї ситуації, коли я намагався вирішити ділення на нуль, що трапляється в моїх даних.

Припустимо, ви хочете обчислити співвідношення чоловіки та жінки для різних шкільних клубів, але ви виявите, що наступний запит виявляється невдалим і видає помилку поділу на нуль, коли він намагається обчислити коефіцієнт для клубу "Володар кілець", в якому немає жінок :

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

Ви можете використовувати функцію, NULLIFщоб уникнути поділу на нуль. NULLIFпорівнює два вирази та повертає нульове значення, якщо вони рівні або перший вираз інакше.

Перепишіть запит як:

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

Будь-яке число, поділене на NULLдає NULL, і помилка не генерується.

Ви також можете це зробити на початку запиту:

SET ARITHABORT OFF 
SET ANSI_WARNINGS OFF

Тож якщо у вас є щось подібне, 100/0воно поверне NULL. Я робив це лише для простих запитів, тому не знаю, як це вплине на довші / складніші.

Ви можете принаймні зупинити запит на розрив із помилкою та повернутись, NULLякщо є поділ на нуль:

SELECT a / NULLIF(b, 0) FROM t 

Однак я б ніколи не перетворював це на нуль, coalesceяк це показано в тій іншій відповіді, яка отримала багато результатів. У математичному сенсі це абсолютно неправильно, і це навіть небезпечно, оскільки ваша програма, ймовірно, поверне неправильні та оманливі результати.

EDIT: Я останнім часом отримую багато зворотних запитів ... тому я подумав, що просто додам зауваження, що ця відповідь була написана до того, як питання було проведено останнє редагування, де в якості опції було вказано повернення нуля. .що здається дуже прийнятним. Частина моєї відповіді була спрямована на такі проблеми, як у Едвардо, у коментарях, які, здається, виступають за повернення 0. Оце я виступив проти мене.

ВІДПОВІДЬ: Я думаю, що тут є основна проблема, яка полягає в тому, що поділ на 0 не є законним. Це вказівка ​​на те, що щось є фундаментально неправильним. Якщо ви ділите на нуль, ви намагаєтесь зробити щось, що математично не має сенсу, тому жодна числова відповідь, яку ви можете отримати, не буде дійсною. (Використання нуля в цьому випадку є розумним, оскільки це не значення, яке буде використано в наступних математичних обчисленнях).

Тож Едвард запитує в коментарях "що робити, якщо користувач поставить 0?", І він виступає за те, щоб було добре, щоб отримати 0 взамін. Якщо користувач вводить нуль у суму, а ви хочете, щоб 0 повернулися, коли вони це роблять, тоді вам слід ввести код на рівні бізнес-правил, щоб отримати це значення і повернути 0 ... не мати спеціального випадку, де поділ на 0 = 0.

Це тонка різниця, але це важливо ... тому що наступного разу, коли хтось зателефонує вашій функції та очікує, що вона зробить правильно, і це зробить щось фанкі, що не є математично правильним, а просто обробляє конкретний край випадку, він має хороший шанс вкусити когось пізніше. Ви насправді не ділите на 0 ... ви просто повертаєте погану відповідь на погану запитання.

Уявіть, що я кодую щось, і я це накручую. Я мав би читати значення масштабу вимірювання випромінювання, але у випадку, коли я не передбачив, я читав у 0. Я потім скидаю своє значення у вашу функцію ... ви повертаєте мені 0! Ура, радіації немає! За винятком того, що він насправді є, і це просто те, що я проходив у поганому значенні ... але поняття не маю. Я хочу, щоб дивізія викинула помилку, оскільки це прапор, що щось не так.

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

Уловивши нуль за допомогою nullif (), то отриманий нуль з isnull () ви можете обійти ділення на нульову помилку.

Заміна "ділити на нуль" нулем суперечливо - але це також не єдиний варіант. У деяких випадках заміна на 1 є (розумно) доцільною. Я часто опиняюся на використанні

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

коли я переглядаю зрушення в балах / підрахунках, і хочу за замовчуванням до 1, якщо у мене немає даних. Наприклад

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

Частіше за все я фактично обчислював це співвідношення десь в іншому місці (не в останню чергу тому, що він може кинути дуже великі коефіцієнти коригування для низьких знаменників. У цьому випадку я, як правило, для OldSampleScore перевищує поріг, який потім виключає нуль . Іноді "хак" доречний.

Я деякий час назад написав функцію, щоб обробляти її для своїх збережених процедур :

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. Додайте обмеження CHECK, яке змушує Divisorбути не нульовим
2. Додайте у форму валідатор, щоб користувач не міг вводити нульові значення в це поле.

Для оновлення SQL:

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

Немає чарівних глобальних налаштувань "поворот поділу на 0 виключення вимкнено". Операція повинна кидатись, оскільки математичне значення x / 0 відрізняється від значення NULL, тому воно не може повернути NULL. Я припускаю, що ви дбаєте про очевидність, і у ваших запитах є умови, які повинні усунути записи з дільником 0 і ніколи не оцінювати поділ. Звичайна "gotcha" - це не те, що більшість розробників очікує, що SQL поводиться як процедурні мови та пропонує коротке замикання логічного оператора, але це НЕ . Рекомендую прочитати цю статтю: http://www.sqlmag.com/Articles/ArticleID/9148/pg/2/2.html

Ось ситуація, коли можна розділити на нуль. Правило бізнесу полягає в тому, що для обчислення оборотів запасів ви приймаєте вартість товарів, що продаються за певний період, анулюють його. Після того, як у вас з'явиться річна кількість, ви поділите на середню кількість запасів за період.

Я дивлюся на підрахунок кількості витків запасів, які трапляються за три місяці. Я підрахував, що у мене вартість товарів, проданих протягом тримісячного періоду, становить 1000 доларів. Річна норма продажу - 4000 доларів (1000 доларів / 3) * 12. Початковий інвентар - 0. Кінцевий інвентар - 0. Мій середній інвентар зараз 0. Я продаю 4000 доларів на рік, а запасів немає. Це дає нескінченну кількість витків. Це означає, що весь мій інвентар переробляється та купується клієнтами.

Це ділове правило, як обчислювати обороти запасів.

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

Відфільтруйте дані, використовуючи пункт де, щоб не отримати 0 значень.

Іноді 0 може бути невідповідним, але іноді 1 теж не підходить. Іноді стрибок від 0 до 100 000 000, описаний як 1 або 100-відсоткова зміна, також може ввести в оману. 100 000 000 відсотків можуть бути доречними в цьому сценарії. Це залежить від того, які висновки ви збираєтесь робити на основі відсотків або співвідношень.

Наприклад, дуже дрібний товар, що переходить від 2-4 проданих, і дуже великопродажний товар, який змінюється від 1 000 000 до 2 000 000 проданих, може означати для аналітика чи керівництва дуже різні речі, але обидва вони виходять як 100% або 1 змінити.

Ізолювати значення NULL може бути простіше, ніж перебирати купу 0% або 100% рядків, змішаних з законними даними. Часто 0 в знаменнику може вказувати на помилку або відсутнє значення, і ви, можливо, не захочете просто заповнити довільне значення лише для того, щоб ваш набір даних виглядав охайним.

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

Ось як я це виправив:

IIF (ValueA! = 0, сумарно / значенняA, 0)

Його можна загорнути в оновлення:

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

Або у вибраному:

SELECT IIF (ValueA! = 0, Total / ValueA, 0) AS Pct FAME від імені таблиці;

Думки?

Ви можете відповідним чином обробити помилку, коли вона розповсюджується на програму виклику (або проігнорує її, якщо ви цього хочете). У C # будь-які помилки, що трапляються в SQL, викинуть виняток, який я можу впізнати, а потім обробити свій код, як і будь-яка інша помилка.

Я погоджуюся з Бескою в тому, що ви не хочете приховувати помилку. Ви не можете мати справу з ядерним реактором, але приховувати помилки взагалі - це погана практика програмування. Це одна з причин, коли більшість сучасних мов програмування реалізують структуровану обробку винятків для декупажу фактичного значення повернення з кодом помилки / стану. Особливо це стосується математики. Найбільша проблема полягає в тому, що ви не можете розрізняти правильно обчислені 0, що повертаються, або 0 в результаті помилки. Натомість будь-яке повернене значення - це обчислене значення, і якщо щось піде не так, викидається виняток. Це, звичайно, буде відрізнятися залежно від способу доступу до бази даних та мови, якою ви користуєтесь, але ви завжди маєте змогу отримати повідомлення про помилку, з яким ви можете мати справу.

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

Використовуйте, NULLIF(exp,0)але таким чином -NULLIF(ISNULL(exp,0),0)

NULLIF(exp,0)перерви, якщо exp є, nullале NULLIF(ISNULL(exp,0),0)не зламається