최상위 데이터베이스 플랫폼에서 부호없는 정수 유형을 사용할 수없는 이유는 무엇입니까?

데이터베이스는 일반적으로 다양한 데이터 유형과 사용자 정의 길이로 매우 사용자 정의 할 수 있습니다.

unsigned intPostgreSQL 및 MS SQL Server에서 사용할 수없는 유형 을 사용하는 구문을 찾으려고 노력하면서 놀랍습니다 . MySQL과 오라클이 보인다.

이것은 부분적으로 눈에 띄지 않는 생략처럼 보입니다. 다음 최고의 성능 옵션은 길고 큰 (8 바이트 정수)이지만 완전히 불필요 할 수 있습니다! 누구나 서명되지 않은 네이티브 지원을 포함하지 않기로 선택한 이유를 아는 사람이 있습니까?

sql-server postgresql datatypes

— 에릭
소스

휴대용 == 표준 필수. C 표준은 일반적인 정수 나 길이의 너비를 나타내지 않고 표현 가능한 숫자의 최소 범위 만 지정합니다. 16 비트 정수를 가진 플랫폼은 어느 시점에서 일반적이었습니다. 64 비트가 가능합니다. 36도 (멸종되었지만). 24가 발생합니다 (DSP). 32 비트가 아닌 31 비트가 아닌 데이터를 보유 하고 일반 숫자 유형을 사용하면 성능이 저하되는 것으로 측정 한 빈도는 ?

— Mat

SQL-Server와 Postgres 모두 NUMERIC(10)정수를 허용 9.999.999.999하고 제약 조건으로 음수 값을 허용하지 않을 수 있습니다.

— ypercubeᵀᴹ November

한 가지 이유 : SQL 표준에 지정되어 있지 않습니다. Postgres에 대한 자세한 설명은 postgresql.1045698.n5.nabble.com/… 과 this : postgresql.1045698.n5.nabble.com/…을 참조하십시오.

— a_horse_with_no_name

SQL Server에 대한 설명은 여기

— Martin Smith

@ 매트 그것은 내가 걱정하는 성능 히트가 아닙니다 .4 여분의 바이트 x 1 억 5,500 만 = ~ 612 여분의 MB가 낭비되며 값은 30 억 이상이지만 40 억이 아닙니다. numeric (10)은 9 바이트의 저장 공간이 필요한 것 외에도 성능에

— 영향을줍니다

Microsoft의 Jim Hogg는 다음과 같이이 문제에 대응했습니다.

찬반 양론이 있습니다. 프로 측에서는 오류를 피하는 좋은 방법 인 것처럼 보입니다. (서명 된) int를 확인 해야하는 값이 0보다 큽니다. 그리고 실제로 int를 많이 사용하면 실제로 음수가 아니어야하는 카운트와 관련이 있습니다. . 최대 행 수를 두 배로 늘리는 문제에 대해? -사실이지만, 이것이 덜 매력적이라고 말하고 싶습니다.

단점은 ... C 또는 C ++에서 부호있는 / 부호없는 유형을 혼합하는 것이 충분히 간단 해야하는 것처럼 보입니다. 그렇지 않습니다. 암시적인 판촉 / 확장에 대한 복잡한 규칙으로 인해 찾기 어려운 실수가 조금 발생합니다. 아아, SQL에는 이미 훨씬 더 복잡한 암시 적 캐스팅 규칙이 있습니다. 서명되지 않은 정수를 추가하면 우리 모두를 더 혼란스럽게 할 것입니다.

나는이 제안들을 책에 보관할 것입니다. 그러나 우리가 추가 할 수있는 모든 기능 중에서이 기능은 그 목록의 최상위에 가깝지 않습니다.

출처 : Microsoft Connect

나는 프로리스트에 크게 추가하고 그들의 SQL 엔진이 이미 이것보다 더 복잡한 일을하고 있다는 것을 반복해서, 그들의 팀은 추가 된 복잡성을 처리 할 수있다. 요약에 동의하지 않지만 이것이 SQL Server가 서명되지 않은 유형을 지원하지 않는 이유 입니다.

Connect 링크는 원래 Martin Smith 가 질문 의견에 게시했습니다 .

— 에릭
소스

"우리 모두를 더 혼란스럽게한다"-아마도 자신의 개발 팀뿐만 아니라 SQL Server를 사용하는 모든 사람을 의미 할 것입니다.

— Oskar Berggren