programing

SQL Server에서 Polymorphic Association을 구현하는 가장 좋은 방법은 무엇입니까?

lovejava 2023. 6. 23. 21:09

SQL Server에서 Polymorphic Association을 구현하는 가장 좋은 방법은 무엇입니까?

데이터베이스에 다형성 연관성을 구현해야 하는 사례가 많습니다.저는 항상 모든 선택지를 다시 생각하는 데 많은 시간을 낭비합니다.여기 제가 생각할 수 있는 3가지가 있습니다.SQL Server에 대한 모범 사례가 있기를 바랍니다.

다중 열 접근법은 다음과 같습니다.

Multiple Column approach

외부 키가 없는 접근 방식은 다음과 같습니다.

No Foreign Key Approach

그리고 여기 기본 테이블 접근법이 있습니다.

Base table approach

이 모델의 또 다른 일반적인 이름은 Supertype Model로, 여기에는 다른 엔티티에 가입하여 확장할 수 있는 기본 속성 집합이 있습니다.오라클의 책에서는 논리적 모델과 물리적 구현 모두를 교육합니다.관계가 없는 모델을 사용하면 데이터가 잘못된 상태로 증가하고 레코드가 분리될 수 있습니다. 해당 모델을 선택하기 전에 필요한 사항을 강력하게 검증할 수 있습니다.기본 개체에 저장된 관계가 있는 상위 모델은 null을 유발하며, 필드가 서로 배타적인 경우에는 항상 null을 가집니다.하위 개체에 키가 적용되는 하단 다이어그램은 null을 제거하지만 종속성을 소프트 종속성으로 만들고 계단식이 적용되지 않은 경우 고아를 허용합니다.그 특성들을 평가하는 것이 가장 적합한 모델을 선택하는 데 도움이 될 것이라고 생각합니다.저는 과거에 세 가지를 모두 사용했습니다.

유사한 문제를 해결하기 위해 다음 솔루션을 사용했습니다.

다-다중 기반 설계: 객체 N과 무언가 사이의 관계가 1-다중 관계이지만, 관계 테이블의 PK를 수정하면 다-다중 관계와 같습니다.

먼저 ObjectN과 Something per Object 간의 관계 테이블을 만든 다음 Something_을 사용합니다.ID 열을 PK로 지정합니다.

이것은 Object2와 Object3에 대해서도 동일한 Something-Object1 관계의 DDL입니다.

CREATE TABLE Something
(
    ID INT PRIMARY KEY,
    .....
)

CREATE TABLE Object1
(
   ID INT PRIMARY KEY,
   .....
)

CREATE TABLE Something_Object1
(
    Something_ID INT PRIMARY KEY,
    Object1_ID INT NOT NULL,
    ......

    FOREIGN KEY (Something_ID) REFERENCES Something(ID),
    FOREIGN KEY (Object1_ID) REFERENCES Object1(ID)
)

이 티켓의 다른 가능한 옵션에 대한 자세한 내용 및 예(동일 비즈니스 규칙에 대한 다중 외부 키)

가장 일반적인 두 가지 접근 방식은 클래스당 테이블(즉, 기본 클래스에 대한 테이블과 각 하위 클래스를 설명하는 데 필요한 추가 열을 포함하는 다른 테이블) 및 계층당 테이블(즉, 한 테이블에 있는 모든 열과 하위 클래스를 식별할 수 있는 열 하나 이상)입니다.어떤 접근 방식이 더 나은지는 애플리케이션 및 데이터 액세스 전략의 세부 사항에 따라 결정됩니다.

첫 번째 예에서는 FK의 방향을 반대로 하고 부모에서 여분의 ID를 제거하여 클래스당 테이블을 갖게 됩니다.다른 두 가지는 기본적으로 클래스당 테이블의 변형입니다.

제 말에 따르면 첫 번째 유형의 접근 방식은 클래스뿐만 아니라 데이터를 정의할 수 있는 가장 좋은 방법이지만 모든 기본 데이터는 아이에게 제공되어야 합니다.

따라서 요구사항을 확인하고 데이터베이스를 정의할 수 있습니다.

접근법 1이 가장 좋지만 어떤 것과 사물 1, 사물 2, 사물 3 사이의 연관성은 1 대 1이어야 합니다.

즉, 하위 테이블(object1, object2, object3)의 FK는 null이 아닌 고유 키이거나 하위 테이블의 기본 키여야 합니다.

object1, object2, object3는 Polymorphic object 값을 가질 수 있습니다.

저는 당신이 기본 테이블 접근법이라고 생각하는 것을 사용했습니다.예를 들어, 이름, 주소 및 전화 번호에 대한 테이블이 있으며, 각각 ID가 PK입니다.그리고 나는 주 엔티티 테이블 엔티티(엔티티)가 있었습니다.ID) 및 연결 테이블: 특성(entityKey, 특성)Type, attributeKey). 여기서 attributeKey는 attributeType에 따라 처음 세 테이블 중 하나를 가리킬 수 있습니다.

몇 가지 이점: 엔티티별로 원하는 만큼의 이름, 주소 및 전화 번호 허용, 새로운 속성 유형 추가, 극단적인 정규화, 공통 속성 마이닝(예: 중복 사용자 식별), 기타 비즈니스별 보안 이점

단점: 단순한 결과 집합을 구축하기 위한 상당히 복잡한 쿼리로 인해 관리하기가 어려웠습니다(예: T-SQL chops를 충분히 갖춘 사람을 고용하는 데 어려움이 있었습니다). 성능은 일반적이지 않고 매우 특정한 사용 사례에 최적이며 쿼리 최적화는 까다로울 수 있습니다.

훨씬 더 긴 경력에서 벗어나 몇 년 동안 이 구조와 함께 살아왔기 때문에, 저는 같은 이상한 비즈니스 논리 제약과 액세스 패턴이 없다면 다시 사용하는 것을 주저할 것입니다.일반적인 용도로 사용할 때는 입력된 표에서 엔티티를 직접 참조하는 것이 좋습니다.즉, 엔티티(엔티티)ID), 이름(이름 ID, 엔티티)ID, 이름), 전화(전화 ID, 엔티티)ID, 전화), 이메일(이메일)신원ID, 이메일).데이터 반복과 공통 열이 있지만 프로그래밍 및 최적화하는 것이 훨씬 쉬워집니다.

이를 달성하기 위한 단일 또는 보편적인 모범 사례는 없습니다.이 모든 것은 애플리케이션에 필요한 액세스 유형에 따라 달라집니다.

이러한 테이블에 대한 예상 액세스 유형에 대한 개요를 작성하는 것이 좋습니다.

  1. OR 계층, 저장 프로시저 또는 동적 SQL을 사용하시겠습니까?
  2. 몇 개의 기록을 예상하십니까?
  3. 여러 하위 클래스 간의 차이는 어느 정도입니까?몇 개의 열?
  4. 집계 또는 기타 복잡한 보고 작업을 수행하시겠습니까?
  5. 보고를 위한 데이터 웨어하우스가 있습니까?
  6. 여러 하위 클래스의 레코드를 한 번에 처리해야 하는 경우가 종종 있습니까? ...

이 질문에 대한 답변을 바탕으로 적절한 해결책을 찾을 수 있습니다.

하위 클래스와 관련된 속성을 저장할 수 있는 한 가지 추가적인 방법은 이름/값 쌍이 있는 테이블을 사용하는 것입니다.이 접근 방식은 서로 다른 하위 클래스가 많거나 하위 클래스의 특정 필드가 자주 사용되지 않는 경우에 특히 유용합니다.

저는 첫 번째 접근법을 사용했습니다.과도한 부하가 걸리면 "Something" 테이블이 병목 현상을 일으킵니다.

테이블 정의의 끝에 속성 전문화가 추가되어 여러 개체에 대해 템플릿 DDL을 사용하는 접근 방식을 취했습니다.

DB 수준에서 서로 다른 클래스를 "Something" 레코드 세트로 표현해야 한다면 그 위에 뷰를 배치합니다.

SELECT "Something" fields FROM object1
UNION ALL
SELECT "Something" fields FROM object2
UNION ALL
SELECT "Something" fields FROM object3

문제는 세 개의 독립 개체가 있다는 점에서 충돌하지 않는 기본 키를 할당하는 방법입니다.일반적으로 사람들은 UUID/GUID를 사용하지만 저의 경우 충돌을 방지하기 위해 시간과 기계를 기반으로 하는 애플리케이션에서 생성된 64비트 정수가 키였습니다.

이 방법을 사용하면 "Something" 개체로 인해 잠금/차단이 발생하는 문제를 피할 수 있습니다.

만약 당신이 "Something" 객체를 변경하고 싶다면, 이것은 어색할 수 있습니다. 이제 당신은 세 개의 독립적인 객체를 가지고 있고, 모든 것은 그들의 구조를 변경해야 합니다.

요약하자면.옵션 1은 대부분의 경우 잘 작동하지만 심각한 부하가 발생할 경우 설계를 분할해야 하는 잠금 차단이 발생할 수 있습니다.

외부 키 열이 여러 개인 접근법 1이 가장 좋습니다.이렇게 하면 다른 테이블과 미리 정의된 연결을 가질 수 있고 스크립트가 데이터를 선택, 삽입 및 업데이트하는 것이 훨씬 쉬워지기 때문입니다.

언급URL : https://stackoverflow.com/questions/7000283/what-is-the-best-way-to-implement-polymorphic-association-in-sql-server