데이터 수집을 처리하고 나중에이 데이터를보고하는 데이터베이스 스키마를 개발 중입니다. 데이터가 다소 스파 스하지만 매우 희소하지 이후 - 요구 사항 토론 후일부 사용자 정의 필드가있는 SQL 데이터베이스 디자인
, 하나의 엔티티 - 속성 - 값 (EAV) 솔루션, 또는 평평한 테이블 솔루션은 괜찮을 것 같다.
그러나 사용자 정의 필드는 앞으로 필수 항목이 될 것이지만 EAV 테이블을 사용하여 RDBMS를 쿼리하고 최적화하는 것이 복잡해질 수 있음을 이해합니다.
토론 here을 살펴 보았습니다. 옵션 1과 유사한 옵션을 사용할 수 있다고 생각했습니다. 예를 들어, 사용자가 레이블을 정의 할 수있는 예비 필드의 수를 설정하십시오.
EAV를 사용하는 대신이 접근법을 사용할 때 단점이 있습니까?
당신은 당신이 새로운 것을 시도하기 전에 데이터 모델 패턴을 기존의 알고 있는지 확인
보고에 관해서 특히, EAV 후회됩니다 Ready to use database model patterns
표 상속을 숙지합니다 : https://martinfowler.com/bliki/UserDefinedField.html
하면 사용자가 자신의 스키마를 수정할 수 있도록 고려
EAV는 거의 항상 아주 나쁜 생각입니다. 위의 방법을 시도한 후에도 여전히 사용자 정의 필드가 필요하다면, 인덱스가있는 BLOB 유형 (JSON 또는 XML)을 사용하십시오 : http://backchannel.org/blog/friendfeed-schemaless-mysql. 포스트 그레스의 바이너리 jsonb는 포스트 그레스에서
을 jsonb'의'내가, 연재 LOB에 깊이보기에 더 걸릴거야'hstore' 열 또는를 사용 쿼리 가능성 측면에서 더 쉽습니다. 필자는 필드가 매우 짧게 존재할 수 있으므로 사용자가 수정할 수있는 스키마가 이상적이라고 생각하지 않습니다 (예 : 내년에 존재하지 않는 새로운 필드). 따라서 EAV 및 JSON 유형 필드는 동적 특성으로 인해 더 매력적입니다. 또한이 [EAV 논문] (https://www.ncbi.nlm.nih.gov/pmc/articles/PMC346624/)도 보았습니다.이 자료는 의료 데이터 수집에서 비교적 일반적으로 사용됩니다. – J3Y
를 조회/빠른 및 인덱싱을 허용하거나 조금 보이지 않는 –