sql-server - 차이 - sql server smallint




SQL Server에서 MONEY 또는 DECIMAL(x, y) 데이터 유형을 선택해야합니까? (8)

나는 money 데이터 유형과 decimal(19,4) (돈이 내부적으로 사용하는 것, 나는 믿는다)와의 실제 차이가 있는지에 대해 궁금합니다.

나는 money 이 SQL 서버에만 해당된다는 것을 알고 있습니다. 다른 하나를 선택해야하는 강력한 이유가 있는지 알고 싶습니다. 대부분의 SQL Server 샘플 (예 : AdventureWorks 데이터베이스)은 가격 정보와 같은 항목에 대해 decimal 가 아닌 money 사용합니다.

돈 데이터 유형을 계속 사용해야하나요? 아니면 10 진수 대신 사용할 수 있습니까? 돈은 입력하는 문자가 적지 만 유효한 이유는 아닙니다. :)


SQLMenace는 돈이 부정확하다고 말했다. 그러나 당신은 돈으로 돈을 번식 / 나누지 않습니다! 3 달러는 50 센트에 얼마입니까? 150 달러? 십진수 여야하는 스칼라로 돈을 곱하거나 나누십시오.

DECLARE
@mon1 MONEY,
@mon4 MONEY,
@num1 DECIMAL(19,4),
@num2 DECIMAL(19,4),
@num3 DECIMAL(19,4),
@num4 DECIMAL(19,4)

SELECT
@mon1 = 100,
@num1 = 100, @num2 = 339, @num3 = 10000

SET @mon4 = @mon1/@num2*@num3
SET @num4 = @num1/@num2*@num3

SELECT @mon4 AS moneyresult,
@num4 AS numericresult

올바른 결과를 얻습니다.

moneyresult           numericresult
--------------------- ---------------------------------------
2949.8525             2949.8525

10 진수가 4 자 이상 필요하지 않는 한 money 이 좋은데, 돈을 나타내는 것이 아닌 스칼라가 decimal 임을 확인하십시오.


WayneM은 돈이 SQL Server에만 한정된다는 것을 알고 있다고 말했습니다. 그러나 그는 십진법을 통해 돈을 사용할 이유가 있는지 묻습니다. 그리고 그 반대도 마찬가지입니다. 분명히 이유를 밝혀야한다고 생각합니다. 십진법을 사용한다는 것은 DBMS를 변경해야하는 경우 걱정하지 않아도된다는 것을 의미합니다. - 일어날 수 있습니다.

시스템을 최대한 유연하게 만드십시오!


나는 MONEY 대 NUMERICAL의 다른 견해를주고 싶다. 내 자신의 전문성과 경험을 기반으로한다. 나는 오랜 시간 동안 그 일을했기 때문에 돈이 많이 든다. .

돈 프로 :

  • 네이티브 데이터 유형 . CPU 레지스터 (32 또는 64 비트)와 동일한 네이티브 데이터 형식 ( 정수 )을 사용하기 때문에 계산시 불필요한 오버 헤드가 필요하지 않으므로 작고 빠릅니다 . 돈이 8 바이트 필요하며 숫자 (19, 4)가 필요합니다. ) 9 바이트 필요 (12.5 % 커) ...

    돈은 그것이 돈을 위해 사용되었다는 이유로 사용되는 한 더 빠릅니다. 얼마나 빠릅니까? 1 백만 데이터에 대한 간단한 SUM 테스트는 MONEY가 275ms이고 NUMERIC 517ms가 ... 거의 두 배 빠름 ... SUM 테스트가 필요한 이유는 무엇입니까? 다음 프로 포인트보기

  • 돈을 위해 최고 . 돈은 예를 들어 회계에 돈을 저장하고 운영하는 데 가장 적합합니다. 단일 보고서는 SUM 연산이 완료된 후 수백만 개의 덧셈 (SUM)과 몇 곱셈을 실행할 수 있습니다. 매우 큰 회계 응용 프로그램의 경우 거의 두 배나 빠르며 매우 중요합니다 ...
  • 낮은 정밀도의 돈 . 실생활에서 돈은 매우 정확할 필요는 없습니다. 내 말은, 많은 사람들이 1 센트 미국 달러를 신경 쓰지만, 0.01 센트 달러는 어떨까요? 사실, 우리나라에서는 은행들이 더 이상 센트를 신경 쓰지 않습니다 (10 진수 쉼표 이후). 나는 미국 은행이나 다른 나라에 대해 모른다.

머니 콘 :

  • 제한된 정밀도 . 머니는 4 자리 숫자 (쉼표 뒤에)의 정밀도를 가지고 있기 때문에 나누기와 같은 작업을 수행하기 전에 변환되어야합니다.하지만 다시 money 은 정확할 필요가 없으며 단지 돈이 아니라 돈으로 사용되기위한 것입니다. 번호 ...

하지만 ... 큰,하지만 여기에 응용 프로그램도 실제 돈과 관련되어 있지만 회계와 같이 많은 SUM 작업에서는 사용하지 마십시오. 만약 당신이 대신 많은 곱셈과 곱셈을 사용한다면 당신은 돈을 사용하면 안됩니다 ...


나는 정확도 주제에서 돈보다 십진법을 사용하는 이유를 발견했다.

DECLARE @dOne   DECIMAL(19,4),
        @dThree DECIMAL(19,4),
        @mOne   MONEY,
        @mThree MONEY,
        @fOne   FLOAT,
        @fThree FLOAT

 SELECT @dOne   = 1,
        @dThree = 3,    
        @mOne   = 1,
        @mThree = 3,    
        @fOne   = 1,
        @fThree = 3

 SELECT (@dOne/@dThree)*@dThree AS DecimalResult,
        (@mOne/@mThree)*@mThree AS MoneyResult,
        (@fOne/@fThree)*@fThree AS FloatResult

그냥 테스트하고 결정하십시오.


방금 SQL Server의 Money vs. Decimal이라는 블로그 항목을 보았습니다.

기본적으로 돈에는 정밀 문제가 있다고 말합니다 ...

declare @m money
declare @d decimal(9,2)

set @m = 19.34
set @d = 19.34

select (@m/1000)*1000
select (@d/1000)*1000

money 유형의 경우 19.34 대신 19.30을 얻게됩니다. 계산을 위해 돈을 1000 부분으로 나누는 애플리케이션 시나리오가 있는지는 잘 모르겠지만이 예제는 몇 가지 제한 사항을 드러내고 있습니다.


우리는 매우 비슷한 문제에 직면했으며 이제는 최상위 수준의 프레젠테이션을 제외하고는 Money를 전혀 사용하지 않은 +1입니다. Google은 역사적인 이유로 하나 이상의 Money 필드가 포함 된 여러 테이블 (실제로 영업 쿠폰 및 판매 송장)을 보유하고 있으며 각 인보이스 세금 중 각 세금 관련 세금 중 상당 부분을 산출하기 위해 비례 계산을 수행해야합니다 판매 바우처의 행. 우리 계산은

vat proportion = total invoice vat x (voucher line value / total invoice value)

그 결과 실물 크기의 돈 / 돈 계산이되어 부서 부분에 규모 오류가 발생하고 잘못된 부분에 배분됩니다. 이 값들이 추후에 합산되면 합계 인보이스 가치와 합쳐지지 않는 부가가치 비율의 합계가됩니다. 괄호 안의 값 중 하나가 10 진수 (나는 그것들 중 하나를 캐스팅하려고합니다)였습니다. 부가 가치세 비율은 정확할 것입니다.

대괄호가 원래는 사용되지 않았을 때 더 큰 값이 포함 되었기 때문에 더 큰 스케일을 효과적으로 시뮬레이트했습니다. 드문 경우지만 계산에 사용할 수있는 정밀도를 불어 넣는 곱셈을 먼저 수행했기 때문에 괄호를 추가했지만 이제는이 오류가 훨씬 많이 발생했습니다.


이전 게시물은 모두 유효한 점수를 가져 오지만 일부는 정확하게 대답하지 않습니다.

질문은 : 덜 정확한 데이터 유형이라는 것을 알고 있고 복잡한 계산에 사용하면 오류를 일으킬 수있는 이유는 무엇입니까?

복잡한 계산을 할 필요가 없을 때 돈을 사용하고 다른 요구에 맞게이 정밀도를 교환 할 수 있습니다.

예를 들어, 위의 계산을 수행 할 필요가 없으며 1 바이트를 절약해야 할 때 (돈은 8 바이트를, 소수 (19,4)는 9 바이트 소요).

또 다른 예는 위의 계산을 할 필요가 없으며 방대한 양의 데이터를 처리하는 데 필요한 속도입니다.

위의 계산을 할 필요가없고 유효한 통화 텍스트 문자열에서 가져올 필요가있는 또 다른 예입니다. 다른 숫자 유형으로 이것을 시도하십시오 : SELECT CONVERT (MONEY, '$ 1,000.68')


절대로 돈을 사용해서는 안됩니다. 그것은 정확하지 않고 순수한 쓰레기입니다. 항상 10 진수 / 숫자를 사용하십시오.

무슨 뜻인지 알아 보려면 이걸 실행하십시오.

DECLARE
    @mon1 MONEY,
    @mon2 MONEY,
    @mon3 MONEY,
    @mon4 MONEY,
    @num1 DECIMAL(19,4),
    @num2 DECIMAL(19,4),
    @num3 DECIMAL(19,4),
    @num4 DECIMAL(19,4)

    SELECT
    @mon1 = 100, @mon2 = 339, @mon3 = 10000,
    @num1 = 100, @num2 = 339, @num3 = 10000

    SET @mon4 = @mon1/@mon2*@mon3
    SET @num4 = @num1/@num2*@num3

    SELECT @mon4 AS moneyresult,
    @num4 AS numericresult

출력 : 2949.0000 2949.8525

돈으로 돈을 나누지 않는다고 말한 사람들에게 :

여기 상관 관계를 계산하는 내 쿼리 중 하나가 있으며,이를 돈으로 변경하면 잘못된 결과가 나타납니다.

select t1.index_id,t2.index_id,(avg(t1.monret*t2.monret)
    -(avg(t1.monret) * avg(t2.monret)))
            /((sqrt(avg(square(t1.monret)) - square(avg(t1.monret))))
            *(sqrt(avg(square(t2.monret)) - square(avg(t2.monret))))),
current_timestamp,@MaxDate
            from Table1 t1  join Table1 t2  on t1.Date = traDate
            group by t1.index_id,t2.index_id




types