Làm cách nào để tránh sự phân chia của các lỗi bằng 0 lỗi trong SQL?

Tôi có thông báo lỗi này:

Msg 8134, Cấp 16, Trạng thái 1, Dòng 1 Chia không có lỗi.

Cách tốt nhất để viết mã SQL là gì để tôi sẽ không bao giờ gặp lại thông báo lỗi này nữa?

Tôi có thể làm một trong những điều sau đây:

• Thêm một mệnh đề where để ước số của tôi không bao giờ bằng 0

Hoặc là

• Tôi có thể thêm một tuyên bố trường hợp, để có một điều trị đặc biệt cho số không.

Là cách tốt nhất để sử dụng một NULLIFmệnh đề?

Có cách nào tốt hơn, hoặc làm thế nào điều này có thể được thi hành?

Để tránh lỗi "Chia cho 0", chúng tôi đã lập trình nó như sau:

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

Nhưng đây là một cách tốt hơn để làm điều đó:

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

Bây giờ vấn đề duy nhất là nhớ bit Null If, nếu tôi sử dụng phím "/".

Trong trường hợp bạn muốn trả về 0, trong trường hợp độ lệch bằng 0 sẽ xảy ra, bạn có thể sử dụng:

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

Với mọi ước số bằng 0, bạn sẽ nhận được số 0 trong tập kết quả.

Đây dường như là cách khắc phục tốt nhất cho tình huống của tôi khi cố gắng giải quyết chia cho số 0, điều này xảy ra trong dữ liệu của tôi.

Giả sử bạn muốn tính tỷ lệ nữ nam cho các câu lạc bộ khác nhau, nhưng bạn phát hiện ra rằng truy vấn sau không thành công và đưa ra lỗi chia cho 0 khi cố gắng tính tỷ lệ cho Câu lạc bộ Chúa tể của những chiếc nhẫn không có phụ nữ :

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

Bạn có thể sử dụng hàm NULLIFđể tránh chia cho số không. NULLIFso sánh hai biểu thức và trả về null nếu chúng bằng nhau hoặc biểu thức đầu tiên khác.

Viết lại truy vấn dưới dạng:

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

Bất kỳ số nào được chia NULLcho NULL, và không có lỗi được tạo ra.

Bạn cũng có thể làm điều này khi bắt đầu truy vấn:

SET ARITHABORT OFF 
SET ANSI_WARNINGS OFF

Vì vậy, nếu bạn có một cái gì đó như 100/0nó sẽ trả về NULL. Tôi chỉ thực hiện điều này cho các truy vấn đơn giản, vì vậy tôi không biết nó sẽ ảnh hưởng đến những truy vấn dài hơn / phức tạp như thế nào.

Ít nhất bạn có thể ngăn truy vấn không bị lỗi và trả về NULLnếu có phép chia cho 0:

SELECT a / NULLIF(b, 0) FROM t 

Tuy nhiên, tôi KHÔNG BAO GIỜ chuyển đổi nó thành Zero bằng cách coalescenó được hiển thị trong câu trả lời khác có nhiều upvote. Điều này là hoàn toàn sai theo nghĩa toán học, và thậm chí còn nguy hiểm vì ứng dụng của bạn có thể sẽ trả về kết quả sai và sai.

EDIT: Gần đây tôi đang nhận được rất nhiều ý kiến ​​trái chiều về vấn đề này ... vì vậy tôi nghĩ rằng tôi chỉ cần thêm một lưu ý rằng câu trả lời này đã được viết trước khi câu hỏi được chỉnh sửa gần đây nhất, trong đó trả về null được tô sáng như một tùy chọn .. .những gì có vẻ rất chấp nhận được. Một số câu trả lời của tôi đã được giải quyết cho những lo ngại như của Edwardo, trong các bình luận, người dường như đang ủng hộ việc trả lại 0. Đây là trường hợp tôi đã chống lại.

TRẢ LỜI: Tôi nghĩ có một vấn đề tiềm ẩn ở đây, đó là phép chia cho 0 là không hợp pháp. Đó là một dấu hiệu cho thấy một cái gì đó sai về cơ bản. Nếu bạn chia cho số 0, bạn đang cố gắng làm điều gì đó không có ý nghĩa về mặt toán học, do đó, không có câu trả lời số nào bạn có thể nhận được sẽ hợp lệ. (Sử dụng null trong trường hợp này là hợp lý, vì nó không phải là giá trị sẽ được sử dụng trong các phép tính toán học sau này).

Vì vậy, Edwardo hỏi trong các ý kiến ​​"điều gì sẽ xảy ra nếu người dùng đặt số 0?", Và anh ta ủng hộ rằng việc lấy lại 0 sẽ không sao. Nếu người dùng đặt số 0 vào số tiền và bạn muốn trả về 0 khi họ làm điều đó, thì bạn nên đặt mã ở cấp quy tắc kinh doanh để bắt giá trị đó và trả về 0 ... không có trường hợp đặc biệt nào khi chia cho 0 = 0.

Đó là một sự khác biệt tinh tế, nhưng nó rất quan trọng ... bởi vì lần sau ai đó gọi hàm của bạn và hy vọng nó sẽ làm đúng, và nó làm một điều gì đó thú vị không đúng về mặt toán học, nhưng chỉ xử lý trường hợp cạnh cụ thể là nó có cơ hội tốt để cắn một ai đó sau này. Bạn không thực sự chia cho 0 ... bạn chỉ đang trả lời một câu trả lời xấu cho một câu hỏi xấu.

Hãy tưởng tượng tôi đang mã hóa một cái gì đó, và tôi làm hỏng nó lên. Tôi nên đọc giá trị tỷ lệ đo bức xạ, nhưng trong trường hợp cạnh lạ mà tôi không lường trước được, tôi đã đọc bằng 0. Sau đó tôi thả giá trị của mình vào hàm của bạn ... bạn trả về cho tôi 0! Hurrah, không bức xạ! Ngoại trừ nó thực sự ở đó và chỉ là tôi đã vượt qua một giá trị xấu ... nhưng tôi không biết. Tôi muốn phân chia để ném lỗi vì đó là cờ rằng có gì đó không đúng.

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

Bằng cách bắt số 0 bằng nullif (), sau đó null kết quả bằng isnull () bạn có thể tránh được phép chia của mình bằng sai số 0.

Thay thế "chia cho 0" bằng 0 là điều gây tranh cãi - nhưng đó cũng không phải là lựa chọn duy nhất. Trong một số trường hợp thay thế bằng 1 là (hợp lý) thích hợp. Tôi thường thấy mình sử dụng

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

khi tôi nhìn vào sự thay đổi về điểm số / số đếm và muốn mặc định là 1 nếu tôi không có dữ liệu. Ví dụ

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

Thường xuyên hơn không, tôi thực sự đã tính tỷ lệ này ở một nơi khác (không phải vì nó có thể đưa ra một số yếu tố điều chỉnh rất lớn cho mẫu số thấp. Trong trường hợp này, tôi thường kiểm soát OldSampleScore lớn hơn ngưỡng; Nhưng đôi khi 'hack' là thích hợp.

Tôi đã viết một hàm một lúc trước để xử lý nó cho các thủ tục được lưu trữ của tôi :

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. Thêm một ràng buộc KIỂM TRA mà buộc Divisorphải khác không
2. Thêm trình xác nhận vào biểu mẫu để người dùng không thể nhập giá trị 0 vào trường này.

Để cập nhật SQL:

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

Không có thiết lập toàn cầu kỳ diệu 'tắt phân chia bằng 0 ngoại lệ'. Thao tác phải ném, vì ý nghĩa toán học của x / 0 khác với nghĩa NULL, vì vậy nó không thể trả về NULL. Tôi giả sử bạn đang quan tâm đến điều hiển nhiên và các truy vấn của bạn có các điều kiện nên loại bỏ các bản ghi với ước số 0 và không bao giờ đánh giá sự phân chia. 'Gotcha' thông thường hơn hầu hết các nhà phát triển mong đợi SQL hoạt động giống như các ngôn ngữ thủ tục và cung cấp ngắn mạch toán tử logic, nhưng KHÔNG . Tôi khuyên bạn nên đọc bài viết này: http://www.sqlmag.com/Articles/ArticleID/9148/pg/2/2.html

Đây là một tình huống mà bạn có thể chia cho số không. Quy tắc kinh doanh là để tính vòng quay hàng tồn kho, bạn lấy chi phí của hàng hóa được bán trong một khoảng thời gian, hàng năm. Sau khi bạn có số hàng năm, bạn chia cho khoảng không quảng cáo trung bình trong khoảng thời gian đó.

Tôi đang xem xét tính toán số lượt hàng tồn kho xảy ra trong khoảng thời gian ba tháng. Tôi đã tính toán rằng tôi có Giá vốn hàng bán trong thời gian ba tháng là $ 1.000. Tỷ lệ bán hàng hàng năm là 4.000 đô la (1.000 đô la / 3) * 12. Khoảng không quảng cáo ban đầu là 0. Khoảng không quảng cáo kết thúc là 0. Khoảng không quảng cáo trung bình của tôi hiện là 0. Tôi có doanh số $ 4000 mỗi năm và không có hàng tồn kho. Điều này mang lại một số lượng vô hạn của lượt. Điều này có nghĩa là tất cả hàng tồn kho của tôi đang được khách hàng chuyển đổi và mua.

Đây là một quy tắc kinh doanh về cách tính vòng quay hàng tồn kho.

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

Lọc dữ liệu bằng cách sử dụng mệnh đề where để bạn không nhận được 0 giá trị.

Đôi khi, 0 có thể không phù hợp, nhưng đôi khi 1 cũng không phù hợp. Đôi khi một bước nhảy từ 0 đến 100.000.000 được mô tả là thay đổi 1 hoặc 100 phần trăm cũng có thể gây hiểu nhầm. 100.000.000 phần trăm có thể phù hợp trong kịch bản đó. Nó phụ thuộc vào loại kết luận bạn dự định rút ra dựa trên tỷ lệ phần trăm hoặc tỷ lệ.

Ví dụ: một mặt hàng bán rất nhỏ chuyển từ 2-4 được bán và một mặt hàng bán rất lớn thay đổi từ 1.000.000 sang 2.000.000 được bán có thể có nghĩa là những điều rất khác nhau đối với một nhà phân tích hoặc quản lý, nhưng cả hai đều đạt 100% hoặc 1 thay đổi.

Có thể dễ dàng cô lập các giá trị NULL hơn là quét qua một loạt các hàng 0% hoặc 100% trộn với dữ liệu hợp pháp. Thông thường, số 0 trong mẫu số có thể chỉ ra lỗi hoặc giá trị bị thiếu và bạn có thể không muốn chỉ điền vào một giá trị tùy ý chỉ để làm cho tập dữ liệu của bạn trông gọn gàng.

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

Đây là cách tôi sửa nó:

IIF (ValueA! = 0, Tổng / ValueA, 0)

Nó có thể được gói trong một bản cập nhật:

SET Pct = IIF (ValueA! = 0, Tổng / ValueA, 0)

Hoặc trong một lựa chọn:

CHỌN IIF (ValueA! = 0, Total / ValueA, 0) NHƯ Pct TỪ Tablename;

Suy nghĩ?

Bạn có thể xử lý lỗi một cách thích hợp khi nó lan truyền trở lại chương trình gọi (hoặc bỏ qua nếu đó là điều bạn muốn). Trong C #, bất kỳ lỗi nào xảy ra trong SQL sẽ đưa ra một ngoại lệ mà tôi có thể bắt và sau đó xử lý trong mã của mình, giống như bất kỳ lỗi nào khác.

Tôi đồng ý với Beska ở chỗ bạn không muốn che giấu lỗi. Bạn có thể không phải đối phó với một lò phản ứng hạt nhân nhưng nói chung các lỗi ẩn là thực hành lập trình xấu. Đây là một trong những lý do hầu hết các ngôn ngữ lập trình hiện đại thực hiện xử lý ngoại lệ có cấu trúc để tách rời giá trị trả về thực tế với mã lỗi / mã trạng thái. Điều này đặc biệt đúng khi bạn đang làm toán. Vấn đề lớn nhất là bạn không thể phân biệt giữa 0 được tính toán chính xác hoặc 0 do lỗi. Thay vào đó, bất kỳ giá trị nào được trả về là giá trị được tính toán và nếu có lỗi xảy ra, một ngoại lệ sẽ bị ném. Điều này tất nhiên sẽ khác nhau tùy thuộc vào cách bạn đang truy cập cơ sở dữ liệu và ngôn ngữ bạn đang sử dụng nhưng bạn sẽ luôn có thể nhận được thông báo lỗi mà bạn có thể xử lý.

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

Sử dụng NULLIF(exp,0)nhưng theo cách này -NULLIF(ISNULL(exp,0),0)

NULLIF(exp,0)nghỉ nếu exp là nullnhưng NULLIF(ISNULL(exp,0),0)sẽ không phá vỡ