이 키가 중복되면 미리 사과해야합니다. 정확히 무엇을 검색해야하는지 잘 모르겠습니다.페더 레이 티드 (가로로 분할 된) 데이터베이스의 기본 키 패턴
최근에 나는 this nifty video on Channel 9 about database federation in SQL Azure을 보았습니다. 처음에는 SQL Azure Federation에서 ID 열을 지원하지 않는다는 사실에 놀랐지 만 의미가 있습니다. 2 개 이상의 데이터베이스로 분할 된 테이블이 있고 ID 증분 값을 공유 할 수있는 방법이 없으면 동일한 주 키를 공유하는 2 개 이상의 엔티티로 끝날 수 있습니다.
비디오는 정수 기반 ID 열 대신 PK에 대해 Guid와 같은 것을 사용하여이 문제를 해결하는 방법을 가볍게 다루었습니다. 최소한 MSSQL은 기본적으로 PK에 클러스터 된 인덱스를 생성하고 Guid (또는 uniqueidentifier) 유형에 클러스터 된 인덱스를 갖는 것은 좋지 않습니다. 필자는 관계형 전문가는 아니지만, PK 기반 조회의 경우 정수 기반 유형과 비교할 때 Guid의 성능이 저하된다고 생각합니다.
이렇게 궁금해졌습니다. 정수 기반 PK 패턴은 수평 적으로 연합 된 데이터베이스처럼 보이게 될까요? 원래 학교 EJB를 작성하고 기본 키에 정수를 생성해야 할 때, rdbms ID/자동 증가 기능을 대체하기 위해 별도의 시퀀스 찾아보기 테이블이 필요했습니다. 나는 그 당시에 EJB가있는 많은 다른 것들이 있었기 때문에 이것이 고통 스럽다는 것을 상기한다.
수평 적으로 연합 된 데이터베이스 테이블에 기본 키를 할당하기 위해 일반적으로 받아 들여지는 패턴은 무엇입니까? 현재의 지식을 감안할 때 성능 저하로 인해 Guid의 기능을 배제 할 것이므로 개발 비용과 복잡성 (주로 개발 비용)으로 인해 순차적 인 조회 색인에서 벗어날 것입니다. 내가 기울여야 할 점 을 향해? 이 같은
주셔서 감사합니다 응용 프로그램의 특성에 따라 유용 할 수 있습니다. 웃긴, MVC4 비동기에 대한 질문을 읽고 자습서를 읽고 답변을 찾고있었습니다. – danludwig
예, 저는 스노우 메이커를 좋아합니다 - 특히 새로운 공급자를위한 인터페이스. 다시 한 번 감사드립니다! – danludwig