SQL Server 10 진수 (9, 0) vs INT

고객 중 하나가 일부 열에 DECIMAL(18,0)SQL Server 2008R2 데이터베이스 의 데이터 유형 을 사용 합니다. 컬럼은 상당히 느리게 성장하기 때문에 최근 DECIMAL(5,0)스토리지를 다시 확보하기 위해 데이터 유형을 변경하도록 제안했습니다 .

MSDN 라이브러리 에 따르면 DECIMAL(5,0)데이터 유형 의 저장 공간은 데이터 유형과 마찬가지로 DECIMAL(9,0)5 바이트입니다. INT는 1 바이트 작지만 저장할 수있는 -99,999 ~ 99,999 대신 -2 ^ 31 ~ 2 ^ 31 범위의 모든 항목을 DECIMAL(5,0)저장할 수 있습니다. DECIMAL5 바이트 ( DECIMAL(9,0))에 맞는 가장 큰 값 조차도 -999,999,999에서 999,999,999 사이의 정수만 저장할 수 있습니다 ( 범위의 절반보다 적은 INT4 바이트).

나는 DECIMALover 를 사용 하는 두 가지 "이점"을 생각할 수 있습니다 INT.

더 많은 저장 공간을 사용하지 않고 확장 성을 추가 할 수있는 기능
데이터 유형을 변경하지 않고 정밀도를 최대 38 자리로 확장하는 기능

그러나 이것들은 내 의견으로는 실질적인 이점이 아닙니다.

정수에 스케일을 추가하는 것은 매우 소수의 경우에만 의미가 있습니다 (대부분의 경우 스케일이 차이가 나는 경우 사전에 추가 할 수도 있음)
SQL Server는 모든 정밀도 / 스케일 조합을 다른 데이터 유형으로 간주하므로 정밀도 또는 스케일을 증가시킬 때 데이터 유형이 단독으로 남아 있지 않습니다.

이것은 나를 궁금하게합니다 : DECIMAL(5,0)정수 에 대한 데이터 유형 의 추가 이점은 무엇입니까?

sql-server t-sql datatypes

— vstrien
소스

한 가지 이점은 5 자리 한도 일 수 있습니다. 그러나 그러한 변화로 얼마나 많은 저장 공간을 절약 할 수 있을지 궁금합니다.

— dezso

IMO, 열 값이 범위 내에 있는지 확인해야하는 경우 검사 제한 조건을 사용하십시오. 이 열이 앞으로 분수 값을 요구할 가능성이 있다면 여기에서 유일한 고려 사항이라고 생각합니다.

— Jon Seigel

저장 공간이 걱정된다면 압축보다 압축에 더 적합합니다. int / bigint 대신 decimal (x, 0)을 사용하면 실질적인 이점이 없습니다.

— Robert L Davis

decimal(x,0)정수형과의 또 다른 차이점은 산술적 분할로 나타납니다. int를 int로 나누면 int를 얻습니다. decimal (x, 0)을 int로 나누면 decimal (x + 6,6)이됩니다.

— Andriy M

@AndriyM, 이것이 가장 큰 이점이라고 생각합니다. 주석 대신 답변으로 바꾸고 답변으로 표시합니다.

— vstrien

답변:

DECIMAL (9, 0) 대 INT 또는 DECIMAL (18, 0) 대 BIGINT를 비교 하는 한 저장 공간 측면에서 실질적인 이점이 없음에 동의합니다 . (1 바이트 이내)

@Andriy와 같은 처리 측면에서 DECIMAL은 자연스럽게 소수 부분을 잃지 않는 유형으로 나눕니다.

반면 에 CPU에서 파이프 라인을보다 효율적으로 파이프 라인 할 때 많은 SUM () 또는 비교 (예 : 값 검색)를 수행하는 경우 기본 INT 유형으로 작업 하는 것이 수치 적 관점에서 훨씬 빠릅니다. int 비교는 두 개의 어셈블리 opcode (MOV, CMP)이지만 소수 비교는 훨씬 더 많습니다.

— 크리스 처브
소스

귀하의 답변은 의미가 있지만 프로세서에는 데이터 유형에 대한 지식이 없습니다. 따라서 4 바이트의 한 데이터 유형은 4 바이트의 다른 데이터 유형만큼 빠르게 비교됩니다. 예를 들어 반복 가능한 성능 테스트 DECIMAL(9, 0)를 통해 INT? 대신에 성능이 저하되었음을 보여줄 수 있습니까 ?

— vstrien

나는 할 수 있다고 생각했지만 내 시험이 결정적이지 않다는 것을 인정할 것이다. 아마도 SQL은 문제를 정수 수학으로 줄이기 위해 최적화를 수행하고 있습니다. 내 테스트 베드 :`--Int 비교 SET @StartTime = SYSDATETIME () WHILE (@CounterINT <@SizeINT) SET @CounterINT = @CounterINT + 1 PRINT 'INT는'+ CONVERT (VARCHAR (20), DATEDIFF (millisecond, @StartTime) , SYSDATETIME ())) + '밀리 초'-소수 SET @StartTime = SYSDATETIME () WHILE (@CounterDEC <@SizeDEC) SET @CountDEDEC = @CountDEDEC + 1 PRINT 'DEC는'+ CONVERT (VARCHAR (20), DATEDIFF (밀리 초, @StartTime, SYSDATETIME ()) + '밀리 초'`

— Chris Chubb

SQL Server가 실제로 무언가를 최적화한다고 생각합니다. 최적화에도 불구하고 DECIMAL여전히 적어도 약간의 시간이 걸립니다 (적어도 내 개발 시스템에서는). 약 51ms DEC vs. 46ms INT.

— vstrien

저장 공간 측면에서 이점이없는 것 같습니다 .

클라이언트가 값이 2 ^ 32-1 (최대 양수 정수를 저장할 수 있음)보다 클 것을 우려하는 경우 BigInt -with는 64 비트 ( 8 바이트)로 이동하는 것을 고려해야 합니다.

— AlexTheDeveloper
소스