고유 ID를 명시 적으로 생성하는 UDF PRIMARY KEY에서 Identity Columns 를 만드는 것이 더 나은지에 대한 논쟁의 여지가 있습니다.
ID_Value의해 호출 되는 하나의 필드로 ID 테이블을 증가시킵니다.1id+1삽입 할 때어떤 구현이 더 합리적입니까?
답변:
당신의 동료는 바보입니다.
솔루션은 확장 할 수 없으며 UDF는 동시 적이 지 않습니다 (이와 같은 이유로 ). 그리고 다중 행 삽입을 처리하는 방법 : 행당 UDF 호출이 필요합니다.
그리고 다른 RDBMS 로의 마이그레이션은 실제 상황에서 자주 발생하지 않습니다. 지금 SQL Server를 사용하지 않고 Oracle에서 시퀀스를 사용하고 마이그레이션하지 않기를 바랍니다.
편집하다:
업데이트는 데이터 이동이 프로덕션 이외의 데이터베이스를 새로 고치기위한 것임을 나타냅니다.
이 경우 새로 고칠 때 ID 열을 무시합니다. 비 Prod로드를보다 쉽게하기 위해 구현을 손상시키지 않습니다. 또는 임시 테이블을 사용하여 ID 값 변경을 추적하십시오.
또는 프로세스 사용 : 매일 밤 생산에서 테스트 시스템을 갱신하여 문제를 완전히 방지합니다. (그리고 우리의 제품 백업도 복원 할 수 있습니다)
항등 값을 사용하십시오. 고유 한 시퀀스 테이블과 시퀀스 값을 생성하면 많은 오버 헤드가 발생하고 숫자를 생성하는 동안 많은 잠금 및 차단이 발생합니다.
신분은 이유가 있기 때문에 사용하십시오.
SQL Denali가 나오면 ID보다 효율적인 시퀀스를 지원하지만 더 효율적인 무언가를 만들 수는 없습니다.
한 환경에서 다른 환경으로 레코드를 이동하는 경우 삽입을 수행 할 때 IDENTITY_INSERT를 ON으로 설정하거나 SSIS에서 확인란을 선택하십시오.
간단한 숫자 ID의 경우 ID를 사용하여 수동으로 생성하는 모든 문제를 잊어 버리십시오.
ID를 PK로 사용하고 유형 열 및 기타 정보가있는 "수퍼 테이블"을 항상 만들 수 있습니다. 새 ID가 필요할 때 (다른 테이블에서 고유 한 IDS를 가정 할 경우)이 테이블에 SCOPE_IDENTITY()삽입 한 다음 필요한 실제 테이블에 삽입하십시오.
기본적으로 당신은 테이블을 만들 : MasterIDs를 신원 PK와 함께, 당신은 당신의 표에 행을 삽입해야 할 때 INSERT INTO MasterIDs와 사용하여 해당 행에 의해 생성 된 ID를 얻을 SCOPE_IDENTITY()다음에 삽입 표 는 PK로 그 값을 사용.
Table1 에는 ID가 아닌 int PK가 있습니다. 같은 프로세스를 Table2에 삽입하는 등의 작업을 수행 할 수 있습니다. SQL Server가 MasterIDs 테이블 의 ID 값을 관리하게 하여 다른 테이블에서 사용할 수 있도록합니다. MasterID 는 유형과 같은 다른 테이블을 포함 할 수 있습니다 (따라서 Table1 또는 Table2 등의 테이블에서 해당 ID 값을 사용하는 것을 알 수 있습니다).
귀하의 시나리오에 맞게 정체성이 만들어졌습니다. 서버 / 환경 데이터 교환을위한 복제와 같은 도구를 모두 갖추고 있습니다.
방금 SQL Server identity열을 일반 int필드 로 교체하고 ID 할당을 직접 제어 하는 작업을 마쳤 습니다.
나는 상당히 인상적인 성능 향상을 보았습니다. OP와 달리 ID를 생성 할 UDF가 없습니다. 그러나 원칙은 거의 동일합니다. 소프트웨어의 일부로 ID 풀을 유지 관리합니다. 그들이 밖으로 실행하면 다음의 데이터베이스를 조회하여 다른 배치를 얻을 낮은 값과 다음에 증분이 높은 .
이를 통해 배치를 데이터베이스에 제출하기 전에 ID를 생성하고 ORM에서 트랜잭션 외부의 모든 엔티티를 연관시킬 수 있으며 추가 라운드 트립없이 더 큰 배치를 제출하여 신원을 삽입 할 수 있습니다 (ID 열에 필요함).
id 테이블에는 하나 이상의 행이 있으므로 원하는 경우 특정 범위를 사용할 수 있습니다. 즉, 삭제 된 블록과 음수 ID를 재사용하기 위해.
나는 수년간 신원을 사용하고 있으며 신원 번호를 UNIQUEIDENTIFIER로 바꾸는 것을 진지하게 고려하고 있습니다. 누군가가 데이터를 컴팩트 db로 설계했다면 데이터 유형을 변경 해야하는 경우 악몽이며 열에 ID를 추가 해야하는 경우 악몽이며 ID 열을 업데이트 할 수 없습니다. int를 넣고 데이터베이스가 20 억 레코드를 넘어서고 다시 악몽으로 바뀌 었다고 상상해보십시오 (FK 고려)! 정체성으로 무엇이든 바꾸는 것은 악몽이며 bigint를 넣지 않으면 규모 친화적이지 않습니다! UNIQUEIDENTIFIER vs Identity = 편의성과 견고성 대 눈에 띄는 성능 향상 (벤치 마이크를하지 않았 음).
업데이트 : 내가 본 후 이 확실히 고유 식별자를 향해 의지. 이것은 bigint identity의 실질적인 이점과 UNIQUEIDENTIFIER의 많은 이점을 보여주지 않습니다! SQL Server 버전마다 결과가 다를 수 있습니다. 모든 데이터베이스와 시스템에서 고유 한 ID를 갖는 것만으로도 아름다움은 있습니다 (견고성)! 원하는대로 데이터를 이동, 복사, 변환하십시오! https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comparison-int-versus-guid/