단일 테이블 상속: 모든 제품 유형에 대해 모든 유형의 모든 속성을 저장할 수 있는 충분한 열이 있는 하나의 테이블을 사용합니다. 즉, 각 행에 많은 열이 있고 그 중 대부분은 지정된 행에서 NULL입니다.
클래스 테이블 상속: 제품에 대한 테이블을 사용하여 모든 제품 유형의 공통 속성을 저장합니다. 그런 다음 각 제품 유형에 대한 테이블을 사용하여 해당 제품 유형과 관련된 속성을 저장합니다.
콘크리트 테이블 상속: 공통 제품 속성에 대한 테이블이 없습니다. 대신, 각 제품 유형에 대해 하나의 테이블을 사용하여 공통 제품 속성과 제품별 속성을 저장하십시오.
직렬화된 LOB: 제품에 대해 하나의 테이블을 사용하여 모든 제품 유형에 공통적인 속성을 저장합니다. 추가 열은 XML, YAML, JSON 또는 기타 형식일 수 있는 반구조화된 데이터의 BLOB를 저장합니다. 이 BLOB를 사용하면 각 제품 유형에 특정한 속성을 저장할 수 있습니다. Facade 및 Memento와 같은 복잡한 디자인 패턴을 사용하여 이 프로세스를 설명할 수 있습니다. 그러나 어쨌든 SQL에서 쉽게 쿼리할 수 없는 BLOB 속성이 있으므로 전체 BLOB를 애플리케이션으로 다시 가져와서 정렬해야 합니다.
Entity-Attribute-Value: 제품에는 테이블을 사용하고 속성을 열 대신 행으로 회전하는 테이블을 사용하세요. EAV는 관계형 패러다임에서 효율적인 설계는 아니지만 여전히 많은 사람들이 사용하고 있습니다. 이것은 다른 답변에서 언급된 "속성 패턴"입니다. 몇 가지 함정에 대해 알아보려면 StackOverflow에서 eav 태그가 붙은 다른 질문을 확인하세요.
EAV에 대한 다른 생각: 많은 사람들이 EAV를 좋아하는 것 같지만 저는 그렇지 않습니다. 이는 가장 유연한 솔루션이므로 최고인 것 같습니다. 하지만 TANSTAAFL이라는 모토를 꼭 기억해주세요. EAV의 몇 가지 단점은 다음과 같습니다.
열을 필수로 만들 수 없습니다(NOT NULL와 동일).
SQL 데이터 유형을 사용하여 항목의 유효성을 검사할 수 없습니다.
속성 이름의 철자를 일관되게 유지할 수 없습니다.
특정 속성 값에 조회 테이블과 같은 외래 키를 배치하는 것은 불가능합니다.
기존 테이블 레이아웃으로 결과를 얻는 것은 복잡하고 비용이 많이 듭니다. 여러 행에 대한 속성을 얻으려면 각 속성에 대해 JOIN 작업을 수행해야 하기 때문입니다.
EAV가 제공하는 유연성은 다른 영역의 희생을 요구하며, 잠재적으로 원래 문제를 보다 전통적인 방식으로 해결한 경우보다 코드를 더 복잡하게(또는 더 나쁘게) 만들 수 있습니다.
그리고 대부분의 경우 그러한 수준의 유연성을 갖는 것은 불필요합니다. 제품 유형에 대한 질문의 경우 각 제품 유형에 대한 테이블을 생성하여 제품별 속성을 저장하는 것이 더 간단할 수 있으므로 동일한 제품 유형의 항목에 대해 최소한 일부 일관된 구조를 적용할 수 있습니다.
각 행이 다른 속성 집합을 가질 수 있는 경우에만 EAV를 사용합니다. 제품 유형이 제한되어 있는 경우 EAV는 과잉입니다. 클래스 테이블 상속이 나의 첫 번째 선택이 될 것입니다.
업데이트 2019: "많은 사용자 정의 속성" 문제에 대한 솔루션으로 JSON을 사용하는 사람들이 많아질수록 이 솔루션이 덜 마음에 듭니다. 이를 지원하는 특별한
기본적으로 관계형 데이터베이스에서는 이러한 솔루션 중 어느 것도 쉽거나 효율적이지 않습니다. "변경 가능한 속성"을 갖는다는 전체 개념은 근본적으로 관계 이론과 일치하지 않습니다.
결국에는 데이터를 쿼리하는 방식과
귀하의 애플리케이션에 가장 덜 나쁜 솔루션이 무엇인지에 따라 이러한 솔루션 중 하나를 선택해야 합니다. 따라서 데이터베이스 디자인을 선택하기 전에 데이터를 쿼리하는 방법을 알아야 합니다. 어느 하나의 솔루션이 애플리케이션에 가장 적합한 선택일 수 있으므로 어느 하나의 솔루션이 "최고"는 아닙니다.
![[웹 프런트엔드] Node.js 빠른 시작](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
@스톤하트
저는 항상 EAV와 MVC를 사용하겠습니다.
@빌 카빈
여기서 언급한 모든 내용:
제 생각에는 어떤 데이터베이스도 애플리케이션의 프로그래밍 언어가 할 수 있는 적절한 수준에서 이러한 상호 작용 및 요구 사항을 처리할 수 없기 때문에 이들 중 어느 것도 데이터베이스에 있어서는 안 됩니다.
제 생각에는 이런 방식으로 데이터베이스를 사용하는 것은 돌에 못을 박는 것과 같습니다. 돌로도 할 수 있지만 이 활동을 위해 특별히 고안된 더 정밀한 망치를 사용해야 하지 않나요?
이 문제는 데이터 일부에 대해 몇 가지 쿼리를 수행하고 이를 테이블 레이아웃으로 처리하면 해결될 수 있습니다. 600GB의 제품 데이터가 있더라도 이 테이블의 각 행에 대한 데이터를 가져와야 하는 경우 일괄 처리할 수 있습니다.
또한 쿼리 성능을 향상시키려는 경우 보고 또는 전역 텍스트 검색과 같은 특정 작업을 선택하고 인덱스 테이블을 준비하여 필요한 데이터를 저장하고 주기적으로(예: 30분마다) 재생성할 수 있습니다.
추가 데이터 저장 비용도 나날이 저렴해지기 때문에 걱정하지 않으셔도 됩니다.
애플리케이션에서 수행하는 작업의 성능이 여전히 걱정된다면 언제든지 Erlang, C++, Go 언어를 사용하여 데이터를 전처리한 다음 기본 애플리케이션에서 최적화된 데이터를 추가로 처리할 수 있습니다.
설명하는 유형 계층 구조를 모델링하기 위해 최소한 다음과 같은 5가지 옵션이 있습니다.
단일 테이블 상속: 모든 제품 유형에 대해 모든 유형의 모든 속성을 저장할 수 있는 충분한 열이 있는 하나의 테이블을 사용합니다. 즉, 각 행에 많은 열이 있고 그 중 대부분은 지정된 행에서 NULL입니다.
클래스 테이블 상속: 제품에 대한 테이블을 사용하여 모든 제품 유형의 공통 속성을 저장합니다. 그런 다음 각 제품 유형에 대한 테이블을 사용하여 해당 제품 유형과 관련된 속성을 저장합니다.
콘크리트 테이블 상속: 공통 제품 속성에 대한 테이블이 없습니다. 대신, 각 제품 유형에 대해 하나의 테이블을 사용하여 공통 제품 속성과 제품별 속성을 저장하십시오.
직렬화된 LOB: 제품에 대해 하나의 테이블을 사용하여 모든 제품 유형에 공통적인 속성을 저장합니다. 추가 열은 XML, YAML, JSON 또는 기타 형식일 수 있는 반구조화된 데이터의 BLOB를 저장합니다. 이 BLOB를 사용하면 각 제품 유형에 특정한 속성을 저장할 수 있습니다. Facade 및 Memento와 같은 복잡한 디자인 패턴을 사용하여 이 프로세스를 설명할 수 있습니다. 그러나 어쨌든 SQL에서 쉽게 쿼리할 수 없는 BLOB 속성이 있으므로 전체 BLOB를 애플리케이션으로 다시 가져와서 정렬해야 합니다.
Entity-Attribute-Value: 제품에는 테이블을 사용하고 속성을 열 대신 행으로 회전하는 테이블을 사용하세요. EAV는 관계형 패러다임에서 효율적인 설계는 아니지만 여전히 많은 사람들이 사용하고 있습니다. 이것은 다른 답변에서 언급된 "속성 패턴"입니다. 몇 가지 함정에 대해 알아보려면 StackOverflow에서 eav 태그가 붙은 다른 질문을 확인하세요.
저는 Scalable Data Modeling이라는 데모에서 이에 대해 더 자세히 썼습니다.
EAV에 대한 다른 생각: 많은 사람들이 EAV를 좋아하는 것 같지만 저는 그렇지 않습니다. 이는 가장 유연한 솔루션이므로 최고인 것 같습니다. 하지만 TANSTAAFL이라는 모토를 꼭 기억해주세요. EAV의 몇 가지 단점은 다음과 같습니다.
NOT NULL와 동일).JOIN작업을 수행해야 하기 때문입니다.EAV가 제공하는 유연성은 다른 영역의 희생을 요구하며, 잠재적으로 원래 문제를 보다 전통적인 방식으로 해결한 경우보다 코드를 더 복잡하게(또는 더 나쁘게) 만들 수 있습니다.
그리고 대부분의 경우 그러한 수준의 유연성을 갖는 것은 불필요합니다. 제품 유형에 대한 질문의 경우 각 제품 유형에 대한 테이블을 생성하여 제품별 속성을 저장하는 것이 더 간단할 수 있으므로 동일한 제품 유형의 항목에 대해 최소한 일부 일관된 구조를 적용할 수 있습니다.
각 행이 다른 속성 집합을 가질 수 있는 경우에만 EAV를 사용합니다. 제품 유형이 제한되어 있는 경우 EAV는 과잉입니다. 클래스 테이블 상속이 나의 첫 번째 선택이 될 것입니다.
업데이트 2019: "많은 사용자 정의 속성" 문제에 대한 솔루션으로 JSON을 사용하는 사람들이 많아질수록 이 솔루션이 덜 마음에 듭니다. 이를 지원하는 특별한
JSON 함수를 사용하더라도 쿼리가 너무 복잡해집니다. JSON 문서를 저장하려면 일반 행과 열에 저장하는 것보다 더 많은 저장 공간이 필요합니다.
기본적으로 관계형 데이터베이스에서는 이러한 솔루션 중 어느 것도 쉽거나 효율적이지 않습니다. "변경 가능한 속성"을 갖는다는 전체 개념은 근본적으로 관계 이론과 일치하지 않습니다.
결국에는 데이터를 쿼리하는 방식과귀하의 애플리케이션에 가장 덜 나쁜 솔루션이 무엇인지에 따라 이러한 솔루션 중 하나를 선택해야 합니다. 따라서 데이터베이스 디자인을 선택하기 전에 데이터를 쿼리하는 방법을 알아야 합니다. 어느 하나의 솔루션이 애플리케이션에 가장 적합한 선택일 수 있으므로 어느 하나의 솔루션이 "최고"는 아닙니다.