데이터베이스 EAV 장단점 및 대안

Question

사용자 정의 필드 및 값 (무제한 숫자 허용)을 허용하는 데이터베이스 솔루션을 찾고 있습니다. 언뜻보기에 EAV는 올바른 착용감처럼 보였지만 일부 독서 후에는 더 이상 확실하지 않습니다.

EAV의 장단점은 무엇입니까?

사용자 정의 속성/필드 및 값을 허용하는 대체 데이터베이스 방법이 있습니까?

Answer 1

이것은 철저한 답변으로 간주되는 것이 아니라 주제에 대한 몇 가지 요점만으로도 간주됩니다.

질문은 또한 태그가 지정되어 있으므로 [sql] 태그, 일반적으로 관계형 데이터베이스 The를 사용하여 데이터를 저장하는 데 특히 적합하지 않습니다 EAV 모델. 여전히 SQL로 EAV 모델을 설계 할 수 있지만 관계형 데이터베이스가 제공 할 많은 이점을 희생해야합니다. 참조 무결성을 시행 할 수 없을뿐만 아니라 값에 SQL 데이터 유형을 사용하고 필수 속성을 시행 할 수있을뿐만 아니라 매우 기본적인 쿼리조차도 쓰기가 어려워 질 수 있습니다. 실제로,이 제한을 극복하기 위해, 몇몇 EAV 솔루션은 관련 테이블과 결합하는 대신 데이터 복제에 의존합니다.

실제로 도식 디자인이 필요한 경우 "무제한의 속성을 허용"하면 가장 좋은 방법은 아마도 NOSQL 해결책. 관계형 데이터베이스에 대한 EAV의 약점은 NOSQL 대안에도 적용되지만 기존 SQL 데이터베이스에서 달성하기 어려운 추가 기능이 제공됩니다. 예를 들어, 일반적으로 NOSQL 데이터 스토어는 관계형 데이터베이스보다 훨씬 쉽게 확장 될 수 있습니다. 단순히 일종의 확장 성 문제를 해결하도록 설계되었으며 스케일링이 어려워지는 기능을 의도적으로 삭제했습니다.

많은 클라우드 컴퓨팅 플랫폼 (예 : 아마존, Google 그리고 마이크로 소프트)는 EAV 모델을 기반으로 한 데이터 스터를 특징으로하며, 임의의 속성이 주어진 엔티티와 관련 될 수 있습니다. 응용 프로그램을 클라우드에 배포하는 것을 고려하고 있다면 큰 공급 업체 간의 강력한 경쟁이 매우 높은 수준으로 추진하고 있기 때문에이를 비즈니스 이점뿐만 아니라 기술적 인 것으로 간주 할 수 있습니다. 지속적으로 기능을 강요하고 재무 및 구현 비용을 낮추어

Answer 2

posgtres hstore를 살펴보십시오 http://www.postgresql.org/docs/9.0/static/hstore.html이것은 대부분의 단점없이 원하는 것을 정확하게 할 것입니다.

Answer 3

그만큼 스트림 플랫폼 대체 방법을 기준으로 제안합니다 스트림 (실제로 도메인 모델입니다), 필드 그리고 과제 엔티티.

Answer 4

사용자 정의 속성/필드 및 값을 허용하는 대체 데이터베이스 방법이 있습니까?

한 가지 대안은 사용자 입력을 기반으로 데이터베이스 스키마를 변경하는 것입니다. 예를 들어 사용자가 새 필드를 원하는 경우 데이터베이스에 해당 열을 추가하십시오.