제 질문의 첫 번째 부분에 대해 : 저는 최근에 관계형 데이터베이스에서 특정 테이블에 대한 고유 식별자를 갖는 이점과 절충점을 스스로에게 묻고있었습니다. 예를 들어 페이스 북 (FB) 그래프 API는 동일한 URL을 사용하여 "사용자", "이벤트", "페이지"등과 같은 여러 유형의 객체를 가져올 수 있습니다. 예 : https://domain/251906384206은 "이벤트"유형의 객체를 반환합니다. https://domain/195466193802264은 "Group"유형의 객체를 반환합니다.의 장점/단점과 관계형 데이터베이스에서 전 세계적으로 고유 한 식별자를 구현하는 방법은 무엇입니까?
덜 일반적인 API를 제공하는 것과 비교하여이 방법의 이점은 무엇입니까? https://domain/event/251906384206 또는 https://domain/group/195466193802264과 같이 사용됩니다. 이 경우, 각 오브젝트 유형에는 식별자 범위가 있기 때문에 유사한 오브젝트 유형에 대해 유사한 식별자가 사용될 수 있습니다.
질문의 두 번째 부분은 다음과 같습니다. 글로벌 고유 ID를 구현하기위한 옵션은 무엇입니까? 내 마음에 와서
두 가지 옵션은 다음과 같습니다
상속 기반 접근 방식을 사용하여 (테이블 당 클래스, 단일 테이블 등). 클래스 당 접근법이 사용된다고 가정하면 (수퍼 테이블은 고유 식별자 만 기본 키로 포함하고, 객체 유형을 나타내는 서브 테이블은 수퍼 테이블 및 추가 데이터와 동일한 식별자를 포함합니다), 수퍼 테이블과 서브 테이블간에 조인이 필요합니다. 수퍼 테이블에 병목이 생기기 때문에?
-
- 고유 식별자
- 개체 유형을 구체적으로 PRIMAR 키 및
- 테이블 명을 포함하는 3 열을 가진 테이블을 제공.
외부 식별자로 고유 식별자를 참조하는 열을 포함하는 개체 유형 당 추가 테이블. 각 오브젝트 유형별 테이블에는 고유 한 기본 키 범위가 있습니다.
두 가지 방법 모두 위에서 언급 한 FB API와 같은 일반적인 API를 제공 할 수 있습니다. 두 번째 방법은 객체 테이블 고유 기본 키를 내부적으로 사용하고 전역 고유 식별자 만 노출하도록 허용합니다. 그러나 전역 고유 식별자가 내부적으로 사용될 수있는 경우 두 번째 방법은 조인도 필요합니다.
세계적으로 고유 한 식별자의 장단점에 관한 경험이 있습니까? 구현을위한 모범 사례는 무엇입니까?
"다시 한번 G.U.I.D를 사용하는 것보다 데이터베이스에서 개체를 나타내는 방법이 더 중요합니다." 틀렸어. 내 질문의 첫 번째 부분은 사용 관점에서 전역 고유 식별자를 사용하는 장단점을 나타냅니다 (예 : 사용하기 쉬운 API를 디자인 할 수 있어야 함). 세계적으로 고유 한 식별자를 필요로한다고 가정 할 때, 제 질문의 두 번째 부분은 전역 적으로 고유 한 식별자를 구현하는 방법에 대한 질문을 말합니다.분명히 몇 가지 옵션이 있습니다. 질문의 후반 부분에 대한 논의는 날짜 기반 디자인 문제를 고려해야합니다. – Scholle
G.U.I.D. 대량의 레코드가 사용되고 있거나 여러 클러스터 또는 서버의 동일한 데이터베이스를 사용할 때 유용합니다. 복제 된 키가 없기 때문입니다. – umlcat