계산 열의 산술 오버플로를 확인 하시겠습니까?

Question

우리는 사용자가 숫자에 대한 다른 데이터베이스 열을 사용하여 산술 표현식 (+ - * /)을 입력 할 수있게 할 것입니다. 그런 다음 응용 프로그램에 의해 구문 분석되고 계산 열로 데이터베이스에 기록됩니다.

그러나 사용자가 0으로 나누기, 산술 오버플로, 그리고 아직까지 나오지 않은 다른 테이블과 같이 select * 테이블을 만들 때 예외가 발생할 수있는 표현식을 만들 수있게하는 데 문제가 있습니다. I 그 모두가라고 생각합니다.

데이터베이스가 select *에 예외를 던지게되면 절대적으로 파괴적입니다. 오히려 오류가 발생하기 쉬운 데이터가있는 경우 정상적으로 실패하는 식으로 식을 다시 작성하려고합니다. 나누기 0으로 솔루션에 대한

은 매우 간단합니다 :

add [Col] as case {divisor} when 0 then N'DIVIDE-BY-ZERO' else {expression} end 

내 질문은 내가 산술 오버 플로우를 위해 할 수있는 무엇인가? 열에 벙커 또는 명백하게 잘못된 데이터를 표시하는 것은 문제가되지 않지만 예외가 발생하면 문제가 발생합니다.

Answer 1

나는 당신이 정말로 당신의 목표에 더 가까워지지 않는 대답을 받아들이는 것을보기를 싫어합니다.

약간의 도움이 될 수있는 답변으로 은 (결정적) 스칼라 UDF를 호출합니다.

참조, 예를 들어,

here 당신이 계산 열을 만들려고하는 경우에 따라서는 생성 된 UDF (또는 여러 UDF)를로 열을 전달하고이 작업을 수행. 스. 라 UDF에서. 제점을 잡아 내기위한 많은 코드를 가질 수 있지만 여전히 TRY/CATCH을 사용할 수는 없습니다. 스칼라 UDF에서 할 수있는 것은 캐치 케이스이며 적절한 답을 반환합니다 (아마도 NULL을 버블 링합니다).

그러나 성능은 될 것입니다 매우, 당신은 열이 지속 만드는 고려할 심각 할 수 있도록 (비 지속 UDF에 대 인라인 계산 된 열을, 우리가 주로 사용 지속에 대해 확실하지) 스칼라 UDF의 가난한 된 후 것 데이터베이스의 공간을 사용하고 삽입 및 업데이트를 약간 느리게 만듭니다. 그것은 큰 상충 관계입니다.

Answer 2

예외를 잡는 것은 어떻습니까? 산술 오버플로의 가능한 원인을 모두 탐지하려고 시도하는 것은 어렵습니다. 일반적으로 예외는 말할 것도 없습니다.

예외에

, 당신과 호환되는 말도 안되는 결과 집합을 반환 할 수 있습니다 원래 사용자 정의 하나 : 당신이 기술을 분석 한 이후

begin try 
    select exp(999) 
end try 
begin catch 
    select 1 
end catch 

Answer 3

, 당신은 모든 잠재적 인 함정에 표현식을 다시 쓸 수 있습니다 오버플로, 다른 유형으로 업 캐스팅 등등.

그러나 나는 이것을 스키마의 일부로 데이터베이스에 넣는다고 생각하지 않기 때문에 그렇게하지 않을 것입니다. 이 도구가 코드 생성 도구가 아니면 훌륭한 아이디어입니다. 사용자는 가장자리 조건에 대한 표현을 검토하고 테스트해야합니다. 마치 원래 데이터베이스 디자인에 포함 된 것처럼.

이미 표현식을 파싱 중이라면 클라이언트 측에서도이 구문을 컴파일하고 행 단위로 오류를 처리합니다.

TRY/CATCH을 사용하여 예외를 catch하는 것은 행 단위가 아닌 모든 또는 모든 시나리오입니다.

Answer 4

성능이 중요한 경우 데이터가 삽입, 업데이트 또는 삭제 될 때 트리거 또는 인덱싱 된 뷰를 사용하여 계산을 저장하십시오.

성능이 중요하지 않은 경우 스칼라 값 함수를 사용하십시오.