@스톤하트

여기까지 오려면 항상 EAV와 MVC를 사용하겠습니다.

@billcavin

여기서 언급한 모든 사항:

• 데이터 검증
• 속성 이름 철자 확인
• 필수 열/필드
• 종속 속성 파괴 처리

제 생각에는 데이터베이스에 전혀 속하지 않습니다. 왜냐하면 어떤 데이터베이스도 애플리케이션의 프로그래밍 언어와 같은 적절한 수준에서 이러한 상호 작용과 요구 사항을 처리할 수 없기 때문입니다.

제 생각에는 이런 방식으로 데이터베이스를 사용하는 것은 돌로 못을 박는 것과 같습니다. 돌로도 할 수 있지만 이런 유형의 활동을 위해 특별히 설계된 더 정확하고 설계된 망치를 사용해야 하지 않나요?

이 문제는 데이터의 일부에 대해 몇 가지 쿼리를 수행하고 애플리케이션을 사용하여 이를 테이블 레이아웃으로 처리하면 해결될 수 있습니다. 600GB의 제품 데이터가 있더라도 이 테이블의 모든 행에 대한 데이터가 필요한 경우 일괄 처리할 수 있습니다.

추가로 쿼리 성능을 향상시키려면 보고 또는 전역 텍스트 검색과 같은 특정 작업을 선택하고 필요한 데이터를 저장하고 주기적으로(예: 30분마다 한 번씩) 재생성되는 인덱스 테이블을 준비할 수 있습니다.

추가 데이터 저장 비용도 나날이 저렴해지기 때문에 걱정하지 않으셔도 됩니다.

애플리케이션에서 수행하는 작업의 성능에 여전히 관심이 있다면 언제든지 Erlang, C++, Go 언어를 사용하여 데이터를 전처리한 다음 기본 애플리케이션에서 최적화된 데이터를 추가로 처리할 수 있습니다. p>

설명하는 유형 계층 구조를 모델링하려면 최소한 다음과 같은 5가지 옵션이 있습니다.

• 단일 테이블 상속: 하나의 테이블은 모든 제품 유형에 적용되며 모든 유형의 모든 속성을 저장할 수 있는 충분한 열이 있습니다. 이는 많은 열이 있음을 의미하며, 그 중 대부분은 특정 행에서 NULL입니다.

• 클래스 테이블 상속: 모든 제품에 공통되는 속성 유형을 저장하는 제품 테이블입니다. 그런 다음 제품 유형당 하나의 테이블을 사용하여 해당 제품 유형과 관련된 속성을 저장합니다.

• 콘크리트 테이블 상속: 공통 제품 속성이 없는 테이블. 대신, 제품 유형당 하나의 테이블에 공통 제품 속성과 제품별 속성이 저장됩니다.

• 직렬화된 LOB: 모든 제품 유형에 공통적인 속성을 저장하는 제품 테이블입니다. 추가 열은 XML, YAML, JSON 또는 기타 형식으로 반구조화된 데이터의 BLOB를 저장합니다. 이 BLOB를 사용하면 각 제품 유형에 특정한 속성을 저장할 수 있습니다. 이를 설명하기 위해 Facade 및 Memento와 같은 멋진 디자인 패턴을 사용할 수 있습니다. 그러나 무슨 일이 있어도 SQL에서 많은 수의 속성을 쉽게 쿼리할 수는 없습니다. 전체 Blob을 다시 애플리케이션으로 추출하여 정렬해야 합니다.

• Entity-Attribute-Value: 제품 테이블과 속성을 열 대신 행으로 회전시키는 테이블입니다. EAV는 관계형 패러다임에 관한 한 유효한 설계는 아니지만 많은 사람들이 여전히 이를 사용하고 있습니다. 이것은 다른 답변에서 언급된 "속성 패턴"입니다. 몇 가지 함정에 대해서는 StackOverflow에서 eav 태그가 붙은 다른 질문을 참조하세요.

Scalable Data Modeling 프레젠테이션에서 작성했습니다.

TANSTAAFL이라는 모토를 기억하세요. EAV의 몇 가지 단점은 다음과 같습니다.

• 열 지정을 강제할 수 없습니다(NOT NULL와 동일).
• SQL 데이터 유형을 사용하여 항목의 유효성을 검사할 수 없습니다.
• 속성 이름의 철자를 일관되게 유지할 수 없습니다.
• 특정 속성 값에 조회 테이블과 같은 외래 키를 배치하는 것은 불가능합니다.
• 기존 테이블 레이아웃에서 결과를 얻는 것은 복잡하고 비용이 많이 듭니다. 여러 행에서 속성을 얻으려면 각 속성에 대해 JOIN 작업을 수행해야 하기 때문입니다.

EAV의 유연성 수준은 다른 영역의 희생을 요구하며, 이는 원래 문제를 보다 전통적인 방식으로 해결하는 것보다 코드를 더 복잡하게(또는 더 나쁘게) 만들 수 있습니다.

그리고 대부분의 경우 이러한 수준의 유연성을 가질 필요는 없습니다. 제품 유형에 대한 OP의 질문에서 각 제품 유형에 대한 제품별 속성에 대한 테이블을 생성하는 것이 훨씬 간단하므로 최소한 동일한 제품 유형의 항목에 대해 일관된 구조를 적용하십시오.

나는 각 행이 잠재적으로 다른 속성 집합을 가질 수 있도록 허용해야 하는 경우에만 EAV를 사용합니다. 제품 범위가 제한되어 있는 경우 EAV는 과잉입니다. 클래스 테이블 상속이 나의 첫 번째 선택이 될 것입니다.

업데이트 2019: 사람들이 "많은 사용자 정의 속성" 문제에 대한 솔루션으로 JSON을 사용하는 것을 볼수록 그 솔루션이 덜 마음에 듭니다. 특별한 JSON 기능，它也会使查询变得过于复杂>을 사용해도 이를 지원합니다. JSON 문서를 저장하려면 일반 행과 열에 저장하는 것보다 더 많은 저장 공간이 필요합니다.

기본적으로 이러한 솔루션 중 어느 것도 관계형 데이터베이스에서 간단하거나 효율적이지 않습니다. "변경 가능한 속성"을 갖는다는 전체 아이디어는 근본적으로 관계 이론과 일치하지 않습니다.

결국 귀하의 앱에 최소한의 영향을 미치는 솔루션을 선택해야 합니다. 따라서 데이터베이스 디자인을 선택하기 전에 데이터를 쿼리하는 방법을 알아야 합니다. 어떤 솔루션이든 특정 애플리케이션에 가장 적합할 수 있으므로 하나의 "최적" 솔루션을 선택할 수 있는 방법은 없습니다.