我写了一个函数来处理我的存储过程:

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

对于更新sql:

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

如果你想返回零，如果发生零分割，你可以使用:

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

对于每一个为0的除数，结果集中都会得到一个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

当错误传播回调用程序时，可以适当地处理它(如果需要，可以忽略它)。在c#中，SQL中发生的任何错误都会抛出一个异常，我可以捕获并在我的代码中处理，就像任何其他错误一样。

I agree with Beska in that you do not want to hide the error. You may not be dealing with a nuclear reactor but hiding errors in general is bad programming practice. This is one of the reasons most modern programming languages implement structured exception handling to decouple the actual return value with an error / status code. This is especially true when you are doing math. The biggest problem is that you cannot distinguish between a correctly computed 0 being returned or a 0 as the result of an error. Instead any value returned is the computed value and if anything goes wrong an exception is thrown. This will of course differ depending on how you are accessing the database and what language you are using but you should always be able to get an error message that you can deal with.

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

添加一个CHECK约束，强制除数为非零 向表单添加验证器，以便用户不能在该字段中输入零值。