GUID VS 자동 증가. (현명하게)

Question

내 시스템 관리자는 실수로 내 데이터베이스를 훨씬 이전 시점으로 복원했습니다.
3 시간 후에 우리는이 시간 동안 80 개의 새 행 (자동 증가 외래 키 종속성 포함)을 작성했습니다.
그래서이 시점에서 병합해야하는 두 개의 테이블에 동일한 ID를 사용하여 80 개의 다른 고객을 확보했습니다.
나는 어떻게 기억 하나 그러나 우리는 이것을 풀었다. 그러나 그것은 오랜 시간이 걸렸다.
이제 새 데이터베이스를 설계하고 있는데,이 사용 사례가 드물 긴하지만 GUID 인덱스를 사용하는 것이 가장 좋습니다.

내 질문 : ID와 같은 긴 문자열을 어떻게 만듭니 까?

두 명의 프로그래머가 고객에 대해 이야기하고있을 때 다음과 같이 말할 수 있습니다.
"안녕하세요. 고객 874454에 문제가 있습니다."
하지만 어떻게 GUID를 사용하면 간단하게 유지할 수 있습니까? 이것은 실제로 문제 및 소통을 일으킬 수있는 문제입니다.
감사합니다.

Answer 1

의 GUID 복제를 사용하고 있지 않습니다. 첫째, SQL Server의 PK에 대한 기본값 인 클러스터 된 인덱스가 아닌지 확인해야합니다. 실제로 삽입 성능을 저하시킬 수 있기 때문입니다. 둘째, int보다 길기 때문에 더 많은 공간을 차지할뿐만 아니라 조인을 더 느리게 만듭니다. 모든 쿼리의 모든 조인.

드문 경우를 해결하기 위해 더 큰 문제를 만들 예정입니다. 대신 실수를 복구하는 데 몇 시간을 들이지 않도록 일을 설정하는 방법을 생각해보십시오.

감사 솔루션을 만들 수 있습니다. 그렇게하면 모든 종류의 실수를 쉽게 복구 할 수 있습니다. 그리고 복구를 위해 사전에 코드를 작성하십시오. 그렇다면 일이 잘못 될 때 수정하는 것이 상대적으로 쉽습니다. 솔직히 저는 회사의 중요한 데이터가 포함 된 데이터베이스가 어떤 형태의 감사없이 설정되는 것을 결코 허용하지 않을 것입니다. 그렇게 위험하지는 않습니다.

또는 임시 위치로 레코드를 이동 한 다음 새 ID로 다시 삽입하고 자식 레코드의 ID를 새 레코드로 업데이트 할 준비가 된 스크립트를 가질 수도 있습니다. 이 작업을 한 번 수행하면 dba가 스크립트를 작성하여 소스 제어에 넣어야하므로 다음 번에 비슷한 수정이 필요할 때 사용할 수 있습니다. dba가 너무 무능해서 이런 종류의 스크립트를 생성하고 저장하지 않으면 그 스크립트를 제거하고 그가하는 일을 아는 사람을 고용하십시오.

Answer 2

대부분의보기에서 접두어 만 표시합니다. 이것이 DVCS가하는 일입니다. 대부분의 객체가 16 진수 해시로 대부분의 객체를 식별하기 때문입니다.

은 (OTOH, 나는 그것이 기본 키에 대한 UUID를 사용하는 많은 서클 유행 알고 있지만 그것은 나를 설득하기 위해 몇 무서운 이야기보다 훨씬 더 걸릴 것)가있는 경우 해결보다 더 많은 문제를 만들 수 있습니다