큰 ID 값을 피해야하는 이유


17

우리는 아직 사용자가 접근 할 수없는 웹 애플리케이션을 개발하고 있습니다. 상사는 테이블에 100 개 미만의 레코드 만 있더라도 새로 작성된 레코드의 ID가 10,000 이상임을 알았습니다. 그녀는 어떤 이유로 든 웹 인터페이스가 실제 레코드보다 100 배 더 많은 임시 레코드를 작성 (삭제)하여 릴리스 후 몇 개월 내에 범위를 벗어날 수 있다고 가정했습니다.

나는 그녀가 ID 인플레이션의 원인에 대해 옳지 않다고 생각합니다 (이에 대답 할 수있는 동료는 휴가 중이므로 확실하지 않습니다). 그녀가 있다고 가정합시다. 그녀는 bigint 열을 사용하는 것을 싫어하고 ID 열 자동 증가를 중지하고 첫 번째 "사용하지 않은"정수를 선택하고이를 ID로 사용하는 서버 측 코드를 작성하고 싶다고 말했습니다.

나는 실무 경험이 거의없는 컴퓨터 공학 대학원생으로, 주니어 개발자 역할을 맡고 있습니다. 그녀는 조직의 모든 데이터베이스를 관리하고 대부분을 설계 한 경험이 있습니다. 나는 이 경우 그녀가 틀렸다고 생각 하고, bigint ID는 두려워 할 것이 없으며 DBMS 기능을 모방하면 반 패턴 냄새가 난다. 그러나 나는 아직 내 판단을 믿지 않습니다.

각 입장에 대한 논쟁은 무엇입니까? bigint를 사용하면 어떤 나쁜 일이 생길 수 있으며 자동 증분 기능 을 다시 개발하면 어떤 위험이 있습니까? 둘 중 하나보다 나은 세 번째 솔루션이 있습니까? ID 액면가의 인플레이션을 피하기 위해 그녀의 이유는 무엇입니까? 나는 실용적 이유에 대해서도 듣고 싶습니다. bigint ID는 이론 상으로는 효과가 있지만 실제로 두통을 유발합니까?

응용 프로그램은 대량의 데이터를 처리 할 것으로 예상되지 않습니다. 앞으로 몇 년 안에 10 만 건의 실제 기록을 달성 할 것으로 의심됩니다.

차이가 있다면 Microsoft SQL Server를 사용하고있는 것입니다. 응용 프로그램은 C #으로 작성되었으며 Linq to SQL을 사용합니다.

최신 정보

감사합니다. 기존 답변과 의견이 흥미로 웠습니다. 그러나 나는 당신이 내 질문을 오해하는 것을 두려워서, 내가 알고 싶은 것을 포함하고 있습니다.

나는 ID가 높은 실제 이유에 대해 정말로 걱정하지 않습니다. 우리가 직접 찾지 못하면 다른 질문을 할 수 있습니다. 내가 관심이있는 것은이 경우의 의사 결정 프로세스를 이해하는 것입니다. 이를 위해 애플리케이션이 하루에 1000 개의 레코드를 작성한 다음 9999 개를 삭제한다고 가정하십시오 . 나는 이것이 사실이 아니라고 확신하지만, 그녀가 요청했을 때 내 상사가 믿었던 것입니다. 따라서 이러한 가상의 상황에서 bigint를 사용하거나 ID를 할당하는 자체 코드를 작성하는 장단점은 무엇입니까 (이미 삭제 된 레코드의 ID를 재사용하여 간격이 없도록)?

실제 이유로, 이것은 나중에 다른 마이그레이션을 어느 정도 수행 할 수 있다는 개념의 증거로 다른 데이터베이스에서 데이터를 가져 오는 코드를 작성했기 때문이라고 생각합니다. 내 동료가 실제로 가져 오는 동안 수천 개의 레코드를 만들어 나중에 삭제했다고 생각합니다. 이것이 실제로 사실인지 확인해야하지만, 그렇다면 실제로 조치가 필요하지 않습니다.



당신은 명확히 할 수 있습니까? 새로운 ID는 단순히 10000보다 큰 값을 얻습니까? 아니면 새 ID의 간격이 10000입니까? 그리고 향후 앱 수명에 몇 개의 ID가 필요할 것으로 예상됩니까?
user2338816

1
사용되지 않은 첫 번째 ID를 찾는 것과 관련하여 Bill Karwin의 저서 "SQL Antipatterns"에 관한 장이 있습니다. 네, 반 패턴으로 보일 수 있습니다!
Thomas Padron-McCarthy

답변:


24

코드를 보지 않으면 무슨 일이 일어나고 있는지 결정하기가 어렵습니다. 대부분의 경우 IDENTITY값이 캐시되고 있기 때문에 SQL Server를 다시 시작한 후 값에 차이가 발생합니다. 이에 대한 좋은 답변과 정보는 /programming/17587094/identity-column-value-suddenly-jumps-to-1001-in-sql-server 를 참조 하십시오 .

간단한 INT필드는 최대 2,147,483,647의 값을 보유 할 수 있습니다. 실제로 32 비트 값을 제공하여 -2,147,483,648에서 ID 값을 시작할 수 있습니다. 40 억 개의 고유 한 값. 사용할 값이 부족할 것입니다. 애플리케이션 추가 된 실제 행마다 1,000 개의 값을 소비한다고 가정하면, IDENTITY값을 0에서 시작하고 INT를 사용 한다고 가정하면 6 개월 내에 ID가 부족하도록 매일 거의 12,000 개의 행을 작성해야합니다 . BIGINT를 사용하는 경우 하루에 12,000 개의 행을 작성하여 행당 1,000 개의 "값"을 소비하는 경우 값이 소진되기 전에 2,100 만 세기를 기다려야합니다.

모든 것을 말했듯 BIGINT이 ID 필드 데이터 유형 으로 사용하려면 분명히 아무 문제가 없습니다. 그것은 모든 의도와 목적에 사용할 수있는 무한한 값의 공급을 제공합니다. INT와 BIGINT의 성능 차이는 최신 64 비트 하드웨어에는 실제로 존재하지 않으며 NEWID()GUID를 생성 하는 데 사용 하는 인스턴스보다 선호 됩니다.

ID 열에 대한 자체 값을 관리하려면 키 테이블을 만들고이 질문에 대한 답변에 표시된 방법 중 하나를 사용하여 키 테이블을 만들 수 있습니다. 키 테이블에 대한 동시 액세스 처리 SQL Server의 교착 상태

다른 옵션은 SQL Server 2012 이상을 사용한다고 가정 할 때 SEQUENCE개체를 사용 하여 열의 ID 값을 얻는 것입니다. 그러나 값을 캐시하지 않도록 시퀀스를 구성해야합니다. 예를 들면 다음과 같습니다.

CREATE SEQUENCE dbo.MySequence AS INT START WITH -2147483648 INCREMENT BY 1 NO CACHE;

"높은"숫자에 대한 당신의 상사의 부정적인 인식에 대한 대답으로, 나는 그것이 어떤 차이점을 말합니까? 를 사용하여 INT필드 를 사용한다고 가정하면 IDENTITY실제로 IDENTITYat을 시작하고 로 2147483647값을 "증가"할 수 -1있습니다. 이는 32 비트 숫자가 4 바이트이므로 0또는에 관계없이 사용되는 메모리 소비, 성능 또는 디스크 공간에 전혀 영향을 미치지 않습니다 2147483647. 0이진수는 0000000000000000000000000000000032 비트 부호있는 INT필드에 저장 될 때 입니다. 2147483647이다01111111111111111111111111111111-두 숫자 모두 메모리와 디스크 모두에서 정확히 같은 양의 공간을 차지하며 처리하려면 정확히 같은 양의 CPU 작업이 필요합니다. 키 필드에 저장된 실제 숫자에 집착하는 것보다 응용 프로그램 코드를 올바르게 설계하는 것이 훨씬 중요합니다.

(a) a와 같은 대용량 ID 열을 사용 BIGINT하거나 (b) ID 격차를 방지하기 위해 자체 솔루션을 롤링 하는 것의 장단점에 대해 문의했습니다 . 이러한 우려에 대한 답변 :

  1. BIGINTINT해당 열의 데이터 유형 대신 . 를 사용 BIGINT하려면 열 자체에 대해 디스크 내 및 메모리 내에서 두 배의 스토리지 양이 필요합니다. 열이 관련된 테이블의 기본 키 인덱스 인 경우 테이블에 연결된 각 비 클러스터형 인덱스는 메모리 BIGINT의 크기 INT와 디스크 의 크기의 두 배로 값을 저장합니다 . SQL Server는 디스크에 데이터를 8KB 페이지로 저장합니다. 여기서 "페이지"당 "행"수는 각 행의 "폭"에 따라 다릅니다. 예를 들어, 열이 10 개인 테이블이 있고 각 INT열이 1 인 경우 페이지 당 160 개의 행을 저장할 수 있습니다. 그 열 대신에BIGINT열의 경우 페이지 당 80 개의 행만 저장할 수 있습니다. 행 수가 매우 많은 테이블의 경우 이는이 예에서 주어진 행 수에 대해 테이블을 읽고 쓰는 데 필요한 I / O가 두 배가됨을 의미합니다. 부여, 이것은 아주 극단적 인 예입니다 - 단일로 구성되는 행이 있다면 INT또는 BIGINT열 단일 NCHAR(4000)열을, 당신은 당신이 사용 여부, 페이지 당 하나의 행을 받고 (단순하게) 것 INT또는를 BIGINT. 이 시나리오에서는 별다른 차이가 없습니다.

  2. ID 열의 차이를 막기 위해 자신의 시나리오를 굴립니다. 사용할 "다음"ID 값을 결정해도 테이블에서 발생하는 다른 작업과 충돌하지 않는 방식으로 코드를 작성해야합니다. 선을 따라 무언가가 SELECT TOP(1) [ID] FROM [schema].[table]순진하게 떠오른다. 테이블에 새로운 행을 동시에 쓰려고 시도하는 액터가 여러 개인 경우 어떻게해야합니까? 두 명의 액터가 동일한 값을 쉽게 얻을 수있어 쓰기 충돌이 발생합니다. 이 문제를 해결하려면 테이블에 대한 액세스를 직렬화하여 성능을 저하시켜야합니다. 이 문제에 관한 많은 기사가 있습니다. 해당 주제에 대한 검색을 수행 할 수 있도록 독자에게 맡기겠습니다.

결론은 요구 사항을 이해하고 응용 프로그램의 동시성 요구 사항과 함께 행 수와 행 너비를 올바르게 추정해야한다는 것입니다. 평소와 같이 It Depends ™.


4
+1이지만 BIGINT의 공간 요구 사항을 버리지 않습니다. 디스크 공간이 아니라 I / O 및 공간이 메모리에 낭비됩니다. 데이터 압축을 사용하여 많은 것을 상쇄 할 수 있으므로 20 억을 초과 할 때까지 BIGINT 유형의 잔인 함을 느끼지 않습니다. 이상적으로는 문제를 해결하는 것입니다 (버그 자체를 망설임). 사람들은 간격에 신경 쓰지 않아야하며 사람들은 하루에 15 번 서버를 다시 시작하지 않아야하지만 두 시나리오가 모두 있습니다. 꽤 널리 퍼져 있으며 종종 함께합니다.
Aaron Bertrand

3
평소와 같이, 매우 유효한 포인트, 아론. 어쨌든 INT를 사용하는 경향이 있습니다 .BIGINT는 많은 수의 행을 기대하지 않는 한 거의 과잉입니다.
Max Vernon

ID 열에 대한 BIGINT 데이터 유형은 동시에 수십만 개 이상의 메모리에 메모리가 없으면 메모리에 큰 영향을 미치지 않습니다. 그럼에도 불구하고 전체 행 크기의 작은 부분이 될 수 있습니다.
user2338816

2
@ user2338816 그게 요점입니다-테이블이 커지면 메모리가 많이 있습니다. 그리고 ID 열은 일반적으로 클러스터링 키이므로 모든 인덱스의 모든 단일 행에 대해 추가로 4 바이트입니다. 모든 경우에 중요합니까? 아니요. 무시해야합니까? 절대적으로하지. 너무 늦기 전에는 확장성에 대해 찢어지지 않는 것 같습니다.
Aaron Bertrand

3
당신이 경우 비록 당신이 필요로 할 수있는 합법적 인 기대가 bigint아마 당신은 사전에 그 결정이 아니라 수십억 개의 행이있는 테이블에이를 추가 할 필요가 자신을 감사 것입니다.
Martin Smith

6

해야 할 주요 작업은 현재 값이 왜 높은 근본 원인을 찾는 것입니다.

테스트 데이터베이스에 대해 이야기하고 있다고 가정하는 SQL2012 이전의 SQL Server 버전에 대한 가장 합리적인 설명은로드 테스트와 정리가 필요하다는 것입니다.

SQL2012부터 가장 가능성이 높은 이유는 SQL 엔진을 여러 번 다시 시작했기 때문입니다 (최대 제공된 Max 링크에 설명 된대로).

테스트 시나리오로 인해 차이가 발생하는 경우 내 관점에서 걱정할 이유가 없습니다. 그러나 안전한면을 유지하기 위해 엔진을 다시 시작하기 전후뿐만 아니라 응용 프로그램을 정상적으로 사용하는 동안 ID 값을 확인했습니다.

MS는 두 대안 (트레이스 플래그 272 또는 새로운 SEQUENCE 객체)이 성능에 영향을 줄 수 있다고 말하고있다.

INT 대신 BIGINT를 사용하여 MS의 다음 "개선"을 보호하기 위해 안전한면에있는 것이 가장 좋은 솔루션 일 수 있습니다 ...


아마 내 질문에 잘못된 방식으로 말했지만, 원인을 찾는 데 관심이 없습니다. 다시 표시되지 않거나 (테스트 실행 결과) 데이터베이스 외부에서 해결할 수있는 응용 프로그램의 잘못된 디자인 결정일 가능성이 높습니다. 요점은 숙련 된 DBA가 ID 관리를 롤링하는 것보다 ID가 높거나 나쁜 것으로 간주하는 이유를 이해하는 것이 었습니다.
rumtscho

2

Rumtscho, 하루에 1000 개의 행만 작성하는 경우, INT 데이터 유형을 ID 필드와 함께 사용하여 수행 할 결정이 거의 없습니다. 간단한 수학은 앱에 30 년의 수명주기를 주면 하루에 20 만 행을 가질 수 있으며 여전히 INT 데이터 유형의 양수 범위 내에있을 수 있다고 말합니다.

BigInt를 사용하면 과도하게 사용되며 Excel 또는 MS Access 등의 ODBC를 통해 앱 또는 데이터에 액세스하는 경우 문제가 발생할 수 있으며 Bigint는 대부분의 ODBC 드라이버에서 데스크톱 앱으로 잘 변환되지 않습니다.

GUIDS는 여분의 디스크 공간과 여분의 I / O를 제외하고는 의도적으로 순차적이지 않은 큰 문제가 있으므로 정렬 된 인덱스의 일부인 경우 모든 삽입물이 인덱스를 사용해야합니다. -짐


NEWSEQUENTIALID ()를 사용하지 않는 한 GUID에 대한 좋은 지적-여전히 동의합니다.이 질문에 명백하게 사용할 이유가 없습니다.
맥스 버논

1

사용 된 값 사이에 차이가 있습니까? 또는 시작 값은 10.000이며 그 이후로 1을 더하고 있습니까? 경우에 따라 고객에게 번호를 제공 할 경우 초기 수가 0보다 큽니다. 예를 들어 1500이라고 가정하면 고객은 시스템이 "신규"임을 인식하지 못합니다.

smallint 대신 bigint를 사용하는 단점은 bigint가 "더 많은 디스크 공간"을 사용하므로 디스크를 읽을 때 모든 디스크에 대해 더 적은 디스크 블록을 읽습니다. 행 공간이 작 으면 중요하지 않은 경우 단점이 될 수 있습니다. 또한 한 번에 많은 리소스를 쿼리하지 않고 적절한 인덱스가 있는지 여부는 중요하지 않습니다.

다른 답변에서 언급했듯이 인덱스가 부족할 염려가 있다면 백만장 사업이 없다면 smallint가 처리 할 수 ​​있습니다. "ID 복구"메커니즘을 개발하는 것은 비용이 많이 들고 소프트웨어에 장애 지점과 복잡성을 추가합니다.

문안 인사


2
서비스 다시 시작시 OP에 차이가 있습니다. 이것은 이 문제 때문입니다 . 또한 smallint가 단기적으로 나중에 고칠 작업에 대한 좋은 절충안이라고 생각하지 않습니다.
Aaron Bertrand

@AaronBertrand는 실제로 다른 사람들 이이 가능성을 제안했을 때 이것을 오해하는 것을 두려워합니다. 나는 이것이 높은 숫자의 원인이 아니라고 확신하지만, 그것이 원인이더라도 원인을 찾으려고 시도하지는 않았지만 제안 된 솔루션에 대해 어떤 주장이있을 수 있는지에 대한 논쟁을 배우려고했습니다. 자세한 내용은 내 업데이트를 참조하십시오.
rumtscho

@rumtscho 실제로이 답변은 귀하의 질문을 직접적으로 다루지 않더라도 좋은 점을 강조합니다. " 'ID 복구'메커니즘을 개발하는 것은 비용이 많이 들고 소프트웨어에 실패 지점과 복잡성을 추가합니다."
Doktor J

@DoktorJ 동의합니다. 나는 대답을 찬성했던 사람이었다 :) 오해를 정리하고 싶었 기 때문에 첫 번째 의견을 남겼습니다.
rumtscho

1

내가 당신의 상사 라면 , 예상치 못한 높은 Id 가치의 이유에 대해 가장 관심 있을 것입니다 .

  1. 이전 테스트에서 ID 값이 폭등 한 경우 예상되는 레코드 수에 대한 다른 의견도 더 작은 키 유형을 제안하도록 강요합니다. 솔직히 말해서 현재 테이블의 용도에 대한 테스트 결과가 문자가 아닌 경우 시퀀스를 재설정하고 기존 레코드의 번호를 다시 매길 수 있는지 고려할 것입니다 (대부분이 과도한 것으로 간주됩니다- '종속적'입니다).

  2. 대신 테이블에 기록 된 대부분의 레코드가 두 테이블 사용을 고려하는 경향이있는 즉시 삭제되는 경우; 레코드가 장기간 보관되지 않는 임시 테이블과 영구적으로 생성 할 레코드 만 보존되는 임시 테이블. 다시 말하지만, 장기 레코드 수에 대한 기대는 키 열에 더 작은 유형을 사용하도록 제안하며 하루에 몇 개의 레코드로 인해 한 테이블에서 다른 테이블로 레코드를 '이동'하는 성능 문제는 거의 발생하지 않습니다. 하나. 귀하의 시나리오가 아닌 것으로 생각되지만 쇼핑 웹 사이트가 Basket / BasketItem을 유지하는 것을 선호하고 주문이 실제로 이루어질 때 데이터가 Order / OrderItem 세트로 이동한다고 상상해보십시오.

요약하면; 내 생각에 BIGINT는 반드시 두려워 할 필요는 없지만, 많은 시나리오에서 솔직히 불필요하게 크다. 테이블이 커지지 않으면 선택한 유형에 과잉이 있음을 결코 알지 못할 것입니다 ...하지만 수백만 행과 많은 FK 열이있는 테이블이있을 때 더 작을 수 있었을 때 BIGINT입니다- 유형은보다 보수적으로 선택되었습니다 (키 열뿐만 아니라 모든 foreigh 키 열 및 보관하는 모든 백업 등을 고려하십시오). 디스크 공간이 항상 저렴한 것은 아닙니다 (관리되는 위치에서 SAN 디스크를 고려하십시오 (즉, 디스크 공간 임대)).

본질적으로 나는 때때로 보다는 항상 데이터 타입 선택을 신중하게 고려할 것을 주장하고있다 . 항상 사용 패턴을 정확하게 예측하지는 않지만 규칙에 따라 더 나은 결정을 내리고 항상 '더 큰 것이 더 좋다'고 가정합니다. 일반적으로 필자는 필 요하고 합리적인 가치 범위를 포함 할 수있는 가장 작은 유형을 선택하며, 가까운 미래에 해당 유형에 적합하다고 생각되면 INT, SMALLINT 및 TINYINT도 기꺼이 고려할 것입니다. 더 작은 유형은 IDENTITY 열과 함께 사용되지 않지만 키 값을 수동으로 설정하는 조회 테이블과 함께 사용할 수 있습니다.

마지막으로 사람들이 사용하는 기술은 기대와 답변에 상당한 영향을 줄 수 있습니다. 일부 툴은 프로세스 당 ID의 사전 예약 범위 등으로 범위에 차이가 발생할 가능성이 높습니다. 반면 @DocSalvager는 상사의 관점을 반영하는 철저한 감사 가능한 순서를 제안합니다. 나는 개인적으로 그 정도의 권위를 요구 한 적이 없다. 비록 신원이 순차적이고 일반적으로 갭이 없다는 일반적인 규칙은 종종 지원 상황과 문제 분석에서 나에게 매우 유용하다.


1

bigint를 사용하거나 ID를 할당하는 자체 코드를 작성하는 것의 장단점은 무엇입니까 (이미 삭제 된 레코드의 ID를 재사용하여 간격이 없도록)?

bigint정체성으로 사용 하고 격차와 함께 생활 :

  • 그것은 모두 내장 기능입니다
  • 즉시 사용할 수 있습니다.
  • int여전히 약 2M 일의 데이터를 제공하기 때문에 공간을 낭비하게됩니다 . 더 많은 페이지를 읽고 써야합니다. 인덱스가 더 깊어 질 수 있습니다. (이러한 볼륨에서 이것은 중요한 관심사가 아닙니다).
  • 대리 키 열은 의미가 없으므로 간격이 양호합니다. 사용자에게 표시되고 격차가 중요하다고 해석되면 잘못하고 있습니다.

자신의 롤 :

  • 개발팀은 모든 개발 및 버그 수정 작업을 영원히 수행 할 것입니다.
  • 꼬리 나 중간에 틈새를 채우고 싶습니까? 논쟁 할 디자인 결정.
  • 모든 쓰기는 동시 프로세스가 동일한 새 ID를 얻지 못하게하거나 사실상의 충돌을 해결하기 위해 강력한 잠금을 발행해야합니다 .
  • 최악의 경우 rowid = 1이 삭제 된 경우 간격을 메우기 위해 테이블의 모든 행을 업데이트해야합니다. 이것은 동시성 및 성능을 떨어 뜨리고 모든 계단식 외래 키 업데이트 등을 수행합니다.
  • 게 으르거나 간절한 갭 필링? 이것이 일어나는 동안 동시성은 어떻게됩니까?
  • 쓰기 = 추가로드 전에 새 ID를 읽어야합니다.
  • 효율적인 간격 찾기를 위해 id 열에 색인이 필요합니다.

0

PK에 대해 INT의 상한 임계 값에 도달하는 것이 실제로 우려되는 경우 GUID 사용을 고려하십시오. 예, 16 바이트 대 4 바이트라는 것을 알고 있지만 디스크는 저렴합니다.

여기의 좋은 쓰기 업 장단점은.


4
이것은 해결책이므로 +1이지만 "디스크가 저렴"한 이유는 옵션을 신중하게 평가하지 않고 GUID를 사용하는 이유가 아닌 이유에 대해서는 Max의 답변에 대한 Aaron의 의견을 참조하십시오 .
Jack Douglas

1
다음은 개발자가 아닌 SQL Server 인덱스 및 아키텍처 전문가의 더 나은 기록입니다. sqlskills.com/blogs/kimberly/disk-space-is-cheap
Aaron Bertrand

아, 물론 NEWID ()의 페이지 분할에주의하십시오.
Max Vernon

1
사장님은 높은 곳에서만 높은 가치에 반대하는 것 같습니다. 나는이 질문이 더 많은 반대 의견을 제시하기를 희망하지만, 이것이 그녀의 주요 주장 중 하나라면 아마도 그녀는 GUID에 더 부정적인 반응을 보일 것이다.
rumtscho

1
@rumtscho 상사에게 대리 숫자는 의미가없는 숫자 (숫자의 "크기"는 무의미한 숫자)이며 시퀀스의 간격은 자연스럽고 피할 수 없다고 말합니다.
Aaron Bertrand

0

RDBMS 기본 키 (일반적으로 'ID'라는 열)
간격은 RDBMS 자동 증가 열 (필드)에서 피할 수 없습니다. 주로 고유 한 PK를 작성하기위한 것입니다. 성능을 위해 주요 제품은 이러한 제품을 일괄 적으로 할당하므로 다양한 정상 작동 결함에 대한 자동 복구 메커니즘으로 인해 숫자가 사용되지 않을 수 있습니다. 이것은 정상입니다.

깨어지지 않은 시퀀스
종종 사용자가 예상되는 등 당신이 끊어지지 않은 일련 번호가 필요합니다, 그것은 프로그램 할당해야하고 별도의 열해야 하지 약동학합니다. 따라서이 1000 개의 레코드는 모두 해당 열에서 동일한 번호를 가질 수 있습니다.

왜 사용자가 끊어지지 않은 시퀀스를 원합니까?
누락 된 시퀀스 번호는 모든 종류의 감사에서 발견 된 가장 기본적인 오류 표시입니다. 이 "Bookkeeping-101"원칙은 어디에나 있습니다. 그러나 수작업으로 유지 관리하는 적은 수의 레코드에 적용되는 것은 데이터베이스의 매우 많은 수의 레코드에 적용될 때 심각한 문제가 있습니다 ...

관련없는 레코드에 키 값을 재사용하면 데이터베이스가 무효화됩니다.
"처음 사용되지 않은 정수"를 사용하면 나중에 언젠가는 원본과 관련이없는 레코드에 숫자가 재사용 될 가능성이 있습니다. 따라서 데이터베이스는 사실을 정확하게 표현하는 데 신뢰할 수 없습니다. 이것이 자동 증가 메커니즘이 절대로 값을 재사용하지 않도록 의도적으로 설계된 이유입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.