데이터베이스에 두 개의 열이 있습니다. 둘 다 ID입니다. 나는 하나의 숫자 자동 증가를 만들고있다. 이것은 기본 키로 선택한 것입니다. 그러나 다른 열은 고유 한 자동 생성 ID도 포함해야합니다. 기본 키의 ID (예 : 숫자 자동 증가 열)와 다른 값이 있어야합니다. 따라서이 열에 GUID를 사용하려고 생각했습니다. 그러나 :열이 기본 키가 아닌 경우 열에 GUID를 사용할 수 있습니까?
열이 기본 키가 아닌 경우 열에 대해 GUID를 사용할 수 있습니까? 좋은 습관입니까?
이것은 가능하며 데이터 크기와 일부 성능 오버 헤드를 제외하고는 문제가되지 않습니다.
외부 시스템과 테이블의 데이터를 동기화해야하는 경우 정상적인 방법입니다. 그런 다음 guid를 사용하여 동기화에 대한 전역 레코드 식별자와 데이터베이스 내부 관계에 대한 숫자 기본 키를 GUID보다 빠르기 때문에 유지 관리합니다.
예, 가능합니다. 좋은 생각인지 여부는 상황에 따라 다르지만 일반적으로 여기에는 문제가 없습니다. 또한 참조 무결성을 적용하기 위해 해당 열에 '고유 키'를 만들어야합니다 (이렇게하면이 열과 관련된 외래 키를 만들 수도 있습니다).
해당 열에 클러스터 된 인덱스를 만들지 않도록하십시오!
GUID 열은 고유하지만 분명히 합치기 위해 커다. 따라서 16 바이트 GUID 열 대신 외래 키 조인 (4 바이트 또는 8 바이트 정수 수량 조인)을 위해 데이터베이스의 숫자 열을 사용하는 것이 바람직 할 수 있습니다 (문자열로 저장하지 않는 한,이 경우에는 32 자리 16 진수와 4 개의 대시). 인덱스는 숫자 열에 대해 더 작습니다. 참조하는 테이블은 더 작을 것이다. 조인 비교가 더 빠 (니다.
따라서 GUID를 기본 키가 아닌 테이블의 보조 (대체) 고유 키로 사용하는 것이 좋습니다.
GUID는 16 바이트 (= 128 비트)입니다. 32는 아니지만 ... - 그 외에는 - 전 당신의 진술에 완전히 동의합니다! –
@marc_s : 정보를 잘못 읽었습니다 (32 자 16 문자 = 16 바이트). 나는 고칠 것이다; 감사. –
고유 한 자동 생성 ID가 두 개 필요합니까? – ean5533
예 - 확실한 이유는 무엇입니까 ?? GUID 열이 기본 키가되어야한다고 생각하게하는 이유는 무엇입니까 ?? GUID는 문자열이나 INT와 같은 또 다른 데이터입니다 - 데이터 만 저장하고 검색하고 수정하십시오 ...... –
@ ean5533 : 아마도 모든 가능한 시스템에서 고유 한 식별자가 있어야합니다. 따라서 GUID는 있지만 DB에있는 항목의 수가 4 바이트 값이 DB 내에서 사용하기에 충분히 작을만큼 작습니까? –