일대일 관계에 INTERLEAVE 테이블 사용

Question

문서 편집기 (스프레드 시트 편집기, 텍스트 문서 편집기, 파워 포인트 편집기 등)의 스키마를 설계하고 있습니다. 편집자는 데이터베이스를 공유하지만 언젠가 별도의 데이터베이스를 사용할 수 있습니다. 각 편집기는 각 문서에 대해 많은 공통 정보를 공유하지만 문서의 종류에 따라 편집기 별 정보도 있습니다.

제 질문은 각 편집기마다 다른 스키마 부분을 디자인하려고 할 때 오는 것입니다. 문서 (예 : ID)에 대한 공통 정보를 보유하고있는 문서 테이블이 있다고 가정합니다. 또한 Doc 레코드와 1 : 1의 관계를 갖는 특정 편집기에 관련된 정보를 연관 시키려고합니다. 내 제안 된 스키마는 다음과 같습니다

CREATE TABLE Docs (
    DocId STRING(MAX) NOT NULL, 
    CreationTime TIMESTAMP NOT NULL, 
    .... 
) PRIMARY KEY (DocId); 

CREATE TABLE SpreadsheetStuff (
    DocId STRING(MAX) NOT NULL, 
    ... spreadsheet-specific information here ... 
) PRIMARY KEY (DocId), 
    INTERLEAVE IN PARENT Docs 
    ON DELETE CASCADE; 

CREATE TABLE TextDocumentStuff (
    DocId STRING(MAX) NOT NULL, 
    ... text-document-specific information here ... 
) PRIMARY KEY (DocId), 
    INTERLEAVE IN PARENT Docs 
    ON DELETE CASCADE; 

별도의 테이블을 가지고에 대한 나의 추론은 편집기 특정 물건에서 공통 부분을 분리하는 것입니다.

이 구조가 기술적으로 작동하더라도 편집자가 필요에 따라 필요에 따라 문서 도구 표를 변경할 수 있으므로 궁금합니다. 즉, 편집기 관련 정보가 포함 된 문서 도구 테이블에 추가 열만 있으면됩니다. 한 가지 우려는 제안 된 구조에 성능이나 다른 의미가 분명하지 않을 수 있다는 것입니다.

이것은 1 : 1 관계에 대한 합리적인 구조입니까? 모범 사례에 대한 확실한 지침이 있습니까?

Answer 1

Cloud Spanner는 limit 열에 가까이 다가 갈 위험이 없다고 가정하면 어느 옵션을 효율적으로 처리 할 수 ​​있습니다. 많은 SQL 쿼리를 수행하려는 경우 두 테이블 접근 방식이 더 복잡 할 수 있습니다. 공식적으로 조인 할 필요가 있기 때문입니다 (조인은 일반적으로 데이터가 인터리브 된 이후에 효율적이어야 함). JOIN의 추가적인 SQL 복잡성에도 불구하고 이것은 아마도 더 깨끗한 접근법 일 것입니다. YMMV.

Answer 2

여기에서 응답하는 CockroachDB는 interleaving tables도 지원합니다.

인터리빙 테이블의 아이디어는 간단히 말해서 자주 읽는 데이터가 동일한 서버에 있으며 적은 수의 출장을 필요로하는 방식으로 데이터가 배치됩니다. 데이터 모델링에 분명히 유용한 기능이 아닌 성능을 향상시키는 도구입니다.

예제에서 제안한 것과 같이 테이블을 의미있게 삽입하려면 User 테이블을 포함시킨 다음 Docs을 삽입하십시오. 이렇게하면 사용자의 모든 문서가 동일한 서버에있을 가능성이 높아 지므로 로그인 한 즉시 모든 사용자의 사용 가능한 문서를 반환하는 것이 더 빠릅니다. 그러면 인터리브 테이블에서 가장 큰 이점을 얻을 수 있습니다 (성능 관점에서).

그러나 질문은 실제로 데이터 모델링에 관한 것이므로 외래 키 관계로 잠재적으로 적용 할 수 있습니다. 이것에 대한 좋은 점은 CockroachDB의 인터리브 된 테이블이 명시 적으로 명시된 관계를 명시 적으로 요구한다는 것입니다 (Cloud Spanner에서는 필요하지 않은 것처럼 보입니다).귀하의 예제 스키마를 사용

는

, 여기이 CockroachDB처럼 보일 것이다 무엇 :

CREATE TABLE Users (
    UserId INT PRIMARY KEY, 
    ..., 
); 

CREATE TABLE Docs (
    UserId INT, 
    DocId INT, 
    CreationTime TIMESTAMP NOT NULL, 
    ..., 
    PRIMARY KEY (UserId, DocId), 
    CONSTRAINT fk_Users FOREIGN KEY (UserId) REFERENCES Users 
) INTERLEAVE IN PARENT Users (UserId); 

CREATE TABLE SpreadsheetStuff (
    UserId INT, 
    DocId INT, 
    PRIMARY KEY (UserId, DocId), 
    ... spreadsheet-specific information here ... 
    CONSTRAINT fk_Docs FOREIGN KEY (UserId, DocId) REFERENCES Docs 
) INTERLEAVE IN PARENT Docs (UserId, DocId); 

CREATE TABLE TextDocumentStuff (
    UserId INT, 
    DocId INT, 
    PRIMARY KEY (UserId, DocId), 
    ...text-document-specific information here ... 
    CONSTRAINT fk_Docs FOREIGN KEY (UserId, DocId) REFERENCES Docs 
) INTERLEAVE IN PARENT Docs (UserId, DocId); 

당신이 다음 쓰고 싶은 것, 쿼리 사용자가 로그인 아마 될 때 뭔가 같은 :

SELECT * FROM Docs WHERE UserId = [this User's ID];

사용자가 한 곳에서 필요한 모든 것을 제공하고 사용자가 문서 중 하나를 클릭하면 편집중인 문서 유형에 대해 특정 표를 쿼리 할 수 ​​있습니다. 그들의 행동에 따라 실제로 다른 프로그램을 여는 것입니다.