Laravel의 다형성 연관성은 단일 연관성을 사용하여 모델이 하나 이상의 다른 모델에 속하는 방법을 제공합니다. 이러한 동적 유연성은 특정 개발 시나리오에서 호소력이 있지만 다형성 연관성에는 데이터베이스 무결성, 성능, 유지 관리 및 확장 성에 영향을 줄 수있는 수많은 잠재적 인 단점이 있습니다.
데이터 무결성 부족 및 외국 주요 제약 조건
Laravel에서 다형성 연관성을 사용하는 데있어 가장 중요한 단점 중 하나는 데이터베이스 수준에서 외국의 주요 제약을 시행 할 수 없다는 것입니다. 다형성 연관성은 일반적으로 관련 모델의 ID를 저장하고 다른 하나는 유형 (클래스 이름)을 문자열로 저장하는 관련 테이블의 두 열에 의존합니다. 이 설계는 외국 키 참조가 관련 모델 유형에 따라 동적으로 변하기 때문에 표준 외국 키 제약 조건을 사용하는 것을 방지합니다. 결과적으로, 데이터베이스 엔진은 참조 무결성을 보장 할 수 없으므로 관련 엔티티가 응용 프로그램에 의해 적절한 계단식 동작없이 삭제되거나 수정되면 고아 또는 일관성이없는 레코드의 위험이 높아집니다.
복잡성 및 성능 문제
다형성 협회는 모든 쿼리가 외국 키 ID와 유형 열에 의해 필터링되어야하므로 쿼리를 복잡하게합니다. 예를 들어, 특정 리소스 유형에 대한 주석을 가져 오려면 ID와 함께 모델 유형을 지정해야합니다. 이 복합 조건은 종종 비효율적 인 쿼리를 초래하여 데이터베이스 최적화기가 인덱스를 효과적으로 사용하기가 어렵 기 때문에 특히 데이터 볼륨이 증가함에 따라 쿼리 실행 속도를 늦 춥니 다. 유형 및 ID 열의 복합 인덱스는 필요하지만 최적화하기 어려울 수 있습니다. 문자열 기반 유형 열 자체는 인덱싱에 오버 헤드를 추가하고 정수 전용 키에 비해 더 많은 저장 공간을 차지하므로 전체 데이터베이스 성능이 저하됩니다.
데이터베이스 정규화 및 단일 책임 원리 위반
다수의 관련이없는 연관성을 동일한 표에 저장함으로써 다형성 협회는 데이터베이스 설계에서 단일 책임의 원칙을 깨뜨립니다. 테이블은 다른 모델에 대한 포획이되며, 이는 다른 속성 세트와 제약 조건을 가질 수 있습니다. 이는 정규화 원칙을 위반하여 스키마를 덜 명확하고 데이터베이스 수준에서 시행하거나 검증하기가 더 어려워집니다. Polymorphic fields store data representing different entities with varying semantics and integrity needs, which complicates schema management and increases the risk of bugs or data anomalies.
유지 보수 복잡성 및 코드 클러 터
다형성 연관성을 구현하면 종종 복잡한 응용 논리가 발생합니다. 예를 들어, 입력 유효성 검사, 모델 라이프 사이클 후크 및 비즈니스 규칙은 단일 다형성 모델 내에서 다른 모델 유형을 조건부로 처리해야 할 수도 있습니다. 이로 인해 코드가 유형 별 조건부 점검으로 혼란스러워서 가독성과 유지 관리가 줄어 듭니다. 모델이 뚜렷한 요구 사항으로 진화함에 따라 단일 다형성 모델은 분리하기 어려운 책임을 축적하여 기술 부채를 초래하는 경향이 있습니다.
열렬한 부하 및 ORM 제한으로 인해 문제가 발생합니다
Laravel의 Eloquent와 같은 ORM 프레임 워크는 다형성 연관성, 특히 열망하는 부하와 관련하여 한계가 있습니다. 다형성 관계는 다중 유형을 동적으로 연결하기 때문에 ORM은 단일 쿼리의 모든 관련 유형에 대한 조인으로 기본적으로 최적화 된 간절한 하중을 수행 할 수 없습니다. 이 제한은 추가 쿼리 또는 복잡한 해결 방법 코드가 N+1 쿼리 문제를 피하고 개발 및 성능 부담을 추가합니다.
고유 한 제약 및 인덱싱을 시행하는 데 어려움이 있습니다
다형성 연관성에 걸친 고유 한 인덱스 또는 제약 조건을 작성하는 것은 관련된 키의 변수 및 복합 특성으로 인해 어렵거나 불가능합니다. 예를 들어, 다형성 키에 고유 한 조합을 보장하려면 유형 열과 ID 열 모두에서 복합 인덱스가 필요하며, 이는 설계 및 유지 관리가 번거 롭습니다. 또한 인덱싱 문자열 기반 유형 열은 정수 외국 키에 비해 느려지고 더 많은 저장 공간을 소비하여 쿼리 비용이 증가합니다.
문자열 유형 열로 인해 낭비 된 데이터베이스 공간
다형성 협회는 문자열 열을 사용하여 관련 모델의 클래스 이름을 저장하는데, 이는 일반적으로 정수 외국 키보다 더 길고 공간 소비입니다. 이 낭비 공간은 수백만 행에 걸쳐 중요 해집니다. 중복 및 긴 유형 이름을 저장하면 테이블 크기가 팽창하여 읽기 및 쓰기 중에 I/O 오버 헤드가 증가 할 수 있습니다.
계단식 삭제 부족으로 인한 오래된 데이터 또는 고아 데이터의 위험
데이터베이스는 다형성 연관에 대한 계단식 삭제로 외국의 주요 제약 조건을 시행 할 수 없으므로 부모 엔터티가 삭제 될 때는 오래된 기록을 축적하기가 쉽습니다. 정리 책임은 전적으로 애플리케이션 코드에 속하며, 종속 다형성 레코드를 삭제하는 것을 잊어 버릴 위험이 높아지며, 이는 고아 또는 유효하지 않은 데이터로 지속될 수 있습니다.
제한된 쿼리 가능성 및 복잡한보고
다형성 테이블 내에 이종 연관성을 저장하면보고 및 집계 쿼리가 복잡해집니다. 관련 레코드가 다른 테이블 또는 유형에 속하기 때문에 일반적인 쿼리, 필터링 또는 그룹화 작업이 더욱 복잡해 지므로 쿼리로 통합하거나 구별하기 위해 추가 논리가 필요합니다. 이 단편화 된 자연은 의미있는 분석을 효율적으로 수행하는 능력을 손상시킵니다.
대안은 다형성 연관성보다 선호됩니다
언급 된 단점으로 인해 개발자는 종종 다형성 연관성에 대한 대안을 권장하여 더 나은 데이터 무결성과 간단한 유지 보수를 달성합니다.
- 별도의 관계 테이블 : 단일 다형성 테이블 대신 각 관계 유형에 대해 명시적인 외국 키가있는 별도의 테이블을 사용하십시오. 이는 기본 데이터베이스 제약 조건으로 데이터 무결성을 유지하고 쿼리 및 인덱싱을 단순화합니다.
- 단일 테이블 상속 (STI) 또는 클래스 테이블 상속 (CTI) : 이러한 접근 방식은 모델 상속 계층을보다 명시 적으로 더 명시 적으로 감소시킬 수 있지만 일부 다형성 복잡성을 줄일 수 있지만 한계가 있고 다른 영역에서는 복잡성이 추가 될 수 있습니다.
- 상속에 대한 구성 : 전용 모델과 관계에 관련 데이터가 캡슐화되어 명확성과 유지 가능성을 향상시키는 선호 구성.