많은 NULL이있는 데이터에 대한 테이블 구조

Question

현재 일부 속성이 있거나 없을 수있는 동적 데이터 개체를 모델링하려고합니다 (속성 이름은 현재 요구 사항에 대해 알려져 있음). 나중에 새 속성을 추가할지 여부는 알 수 없습니다 (그러나 거의 확실합니다). 모델링 된 객체는이 라인을 따라 뭔가 :

int id PRIMARY KEY NOT NULL; 
int owner FOREIGN KEY NOT NULL; 
Date date NOT NULL; 
Time time NOT NULL; 
Map<String,String> properties; 

속성은 모든 유형 (INT, 부울, 문자열, ...)

나는이 모델링하는 방법을 잘 모르겠어요이 될 수 있습니다 SQL 데이터베이스의 개체. 이 작업을 수행 할 수있는 두 가지 방법이 있으며 개발자 "작업"(유지 관리), 메모리 소비 및 성능면에서 더 나은 선택이 될 수있는 몇 가지 정보를 원합니다. 부울 정보 : 속성은 거의 항상 NULL (존재하지 않음)입니다.

(1) ID, 소유자, 날짜, 시간 및 모든 속성이있는 열이없는 큰 테이블은 열 속성이없는 반면 NULL로. 예 :

TABLE_X 
id|owner|date|time|prop_1|prop_2|prop_3|... 

이 테이블에는 많은 NULL 값이 있습니다.

새로운 속성을 첨가해야 내가 ALTER 표를하고 여기에

내가이 "보통"을 할 것마다 새 속성에 대한 새 열을 삽입 할 경우

SELECT * FROM TABLE_X ... 

(2) 내가 것

TABLE_X 
id|owner|date|time 

을 그리고 다음과 같이 모든 속성에 대해 별도의 테이블이 있습니다 : 모든 NOT NULL 데이터를 메인 테이블이

TABLE_X_PROP_N 
foreign_key(TABLE_X(id))|value 

여기에는 전혀 NULL 값이 없습니다. 속성이 값을 갖고 해당 테이블에 있거나 값이 NULL이고 해당 테이블에 나타나지 않습니다.

새 속성을 추가하려면 다른 테이블을 추가하면됩니다. 여기

질문 (그래서 당신은 스크롤 할 필요가 없습니다) 반복하려면

SELECT * FROM TABLE_X LEFT JOIN TABLE_X_PROP_1 ON ... LEFT JOIN TABLE_X_PROP_2 ON ... 

할 것입니다 : 유지 보수 측면에서 더 나은 문제를 다루는 boths 방법 (개발자 용), 메모리 소비 (디스크) 및 성능 (초당 쿼리 수)? 어쩌면 당신도이 문제를 어떻게 처리 할 수 ​​있을지 더 잘 알고있을 것입니다. 미리 감사드립니다.

Answer 1

, 내가 생각 : : 그냥 하나 개의 테이블에 모든 것을 넣어 | 소유자 | 날짜 |

TABLE_HEADER
ID를 시간

TABLE_PROPERTY
id | name

TABLE_PROPERTYVALUE
id | headerID (FK) | propertyID (FK) | 값

새 속성을 쉽게 추가 할 수 있으므로 유연성이 향상되고 훨씬 빠르게 반복 할 수 있습니다. 등록 정보의 수는 영향을 미칩니다 (예를 들어 500 개의 등록 정보가있는 경우 500 개의 열이있는 테이블을 원하지 않을 수도 있음). 주된 단점은 복잡한 비즈니스 로직을 속성을 사용하여 복잡한 네비게이션 구조로 연결할 필요가 있고 특정 필드에 대해 null이 아닌 것처럼 데이터 무결성을 적용 할 수없는 경우 추악해진다는 것입니다. 당신이 정말로 당신의 객체 구조에서 모델링 한 것과 같은 속성 가방을 원한다면 쉽게 매핑됩니다. 모든 것과 마찬가지로 가장 적합한 것에 대한 상황에 따라 다릅니다.

Answer 2

해결 방법 2. 모든 속성에 대해 별도의 표가없는 이유는 무엇입니까?당신이 3 개 테이블이 필요하면 옵션 2로 가면

properties(
foreign_key(TABLE_X(id)) 
property_name, 
value); 

Answer 3

여기 엔 Entity-Attribute-Value (종종 anti-as-an-anti-pattern) 패턴을 구현하려는 것 같습니다. 당신은 그들과 친하십니까? 여기 몇 가지 참조 :

https://softwareengineering.stackexchange.com/questions/93124/eav-is-it-really-bad-in-all-scenarios

http://www.dbforums.com/showthread.php?1619660-OTLT-EAV-design-why-do-people-hate-it

https://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model

개인적으로 나는 RDBMS의 설정이 유형의 매우 조심 해요. 나는 NoSQL 문서 스타일 데이터베이스가 이러한 유형의 동적 구조에 더 적합하다고 생각하는 경향이 있지만 실제로 NoSQL에 대한 실제 경험은 비교적 적습니다.