변수 열을 사용하여 테이블 디자인을 처리하는 방법

테이블 디자인 시나리오가 있으며 비 DBA 유형으로 더 확장 가능한 의견이 필요합니다.

작은 동네 (200 채의 주택)부터 시작하여 5000000 개 이상의 주택으로 자라는 대도시 지역의 주택에 대한 정보를 기록하라는 메시지가 표시됩니다.

기본 정보를 저장해야합니다 : ID # (고유 인덱스로 사용할 수있는 고유 로트 번호), Addr, City, State, Zip. 훌륭하고 간단한 테이블이 처리합니다.

그러나 매년 모든 주택에 대한 추가 정보를 기록하라는 요청을 받게되며 매년 정보가 변경됩니다. 예를 들어 첫해에는 소유자의 성 및 평방 피트를 기록하라는 메시지가 표시됩니다. 두 번째 해에는 성을 유지하라는 요청을 받지만 제곱 피트를 버리고 대신 소유자 이름을 수집하기 시작합니다.

마지막으로 매년 추가 열 수가 변경됩니다. 2 개의 추가 열로 시작한 다음 내년에 6으로 이동 한 다음 다시 2로 내려갈 수 있습니다.

따라서 한 가지 테이블 접근 방식은 사용자 정의 정보를 하우스 테이블의 열로 추가하여 하나의 테이블 만 사용하는 것입니다.

그러나 누군가 누군가 이것을 위해 테이블을 배치 한 상황이 있습니다.

"집 테이블"열 : ID, 주소, 도시, 주, 우편 번호-집당 한 행

ID   Addr              City     State  Zip 
-------------------------------------------
1    10 Maple Street   Boston      MA  11203

2    144 South Street  Chelmsford  MA  11304

3    1 Main Avenue     Lowell      MA  11280

"맞춤 정보 테이블"열 : ID, 이름, 값-다음과 같은 테이블 :

ID   Name             Value

1    Last Name        Smith

2    Last Name        Harrison

3    Last Name        Markey

1    Square Footage   1200

2    Square Footage   1930

3    Square Footage 

따라서 각 개별 주택 기록에 대해 여러 행이 있습니다. 매년 선택적 정보가 필요한 경우이 테이블은 문자 그대로 다시 작성되므로 내년에는 다음과 같이 보일 수 있습니다.

1    Last Name    Smith

2    Last Name    Harrison

3    Last Name    Markey

1    First Name   John

2    First Name   Harry

3    First Name   Jim

결국 당신은 10 만 개의 행을 모으고 1 년 동안 10 개의 추가 정보가 있습니다. 두 번째 표는 현재 1,000,000 행의 정보이며, 그 중 다수는 중복 (설명) 정보를 가지고 있습니다. 전체 데이터베이스 요구 사항은 사람들이 하루에 수천 번 하우스 행 정보 + 관련 사용자 정의 필드 값을 가져와야한다는 것입니다.

그래서 내 질문 : 대신 다음 중 하나를 수행하는 것이 나쁜 (또는 끔찍한) 연습입니까?

A) 최대 맞춤 열 수 ( '1'~ '10'이라고 함)를 추측하여 하우스 테이블을 배치하고 해당 맞춤 값을 하우스 행에 바로 삽입합니다.

또는

B) 커스텀 정보를 하우스 테이블에 저장하십시오. 그러나 요구 사항이 변경 될 때마다 커스텀 정보에 필요한 열 수만으로 하우스 테이블을 다시 작성하십시오. 선택적 필드가 필요할 수 있습니까?

감사합니다. 이것이 의미가 있기를 바랍니다.

거의 4 가지 선택이 있습니다.

NoSQL에 - 정의 모든 기록은 키 / 값 쌍의 집합으로 저장됩니다. 매우 유연하고 빠릅니다. 모든 보고서 작성자가이 스토리지 유형을 지원하지는 않습니다. NoSQL의 데이터베이스 구현 예제는 많이 있습니다. 현재 가장 인기있는 것으로 보이는 것은 MongoDB입니다.

EAV - 정의 하면 전체 테이블 또는 옆으로 (다른 테이블) 부분 중 하나를 설정하는 곳입니다. 사내 관계형 데이터베이스가있어 쉽게 이동할 수없는 경우이 방법을 사용하는 것이 좋습니다. 제공 한 사용자 정의 정보 테이블 예는 EAV 테이블의 좋은 예입니다.

XML 열이있는 표준 테이블 -NoSQL이 관계형 테이블을 충족한다고 생각하십시오. XML 열에 저장된 데이터는 여러 개의 상관 된 하위 데이터를 포함하여 XML이 지원하는 모든 형식 일 수 있습니다. 알고있는 열이 "정규"열인 경우 데이터를 저장하기에 적합한 열 유형으로 구축 할 수 있습니다 (성, 주소, 도시, 주 등).

추가 열 이 많은 표준 테이블 -관계형 데이터베이스가 있고 XML 또는 EAV를 사용할 수 없으며 NoSQL은 옵션이 아닙니다. 각 유형의 추가 열을 많이 추가하십시오. 나는 30 개 이상의 varchar, 30 개 이상의 정수, 15 개 이상의 숫자를 추측합니다. 그리고 값으로 열을 사용한 후에 는 재사용하지 마십시오 . 그리고 열도 삭제하지 마십시오 .

이 모든 솔루션 중에서, 제 생각에는 NoSQL 또는 EAV 접근 방식이 코드와 스키마를 최소한의 리팩토링으로 가장 성공할 수 있다는 것입니다.

다음 해가 아닌 1 년 동안 데이터를 수집 한 다음 나중에 다시 수집하는 상황이 있습니다. 올바른 정보로 오래된 데이터를 업데이트하려고하면 문제가 발생하고 비용이 많이 듭니다. 스토리지도 마찬가지입니다.

이 두 가지 옵션에 대한 귀하의 질문에 대답하는 것은 나에게 옳지 않은 것 같습니다. A)가 당신을 잠그고 B)는 많은 일입니다. 설명하는 현재 스키마는 조회 테이블을 참조하는 ID 대신 문자열로 정보 이름 ( "이름", "평방 피트"등)을 제외하고는 나쁘지 않습니다.

그러나 이것은 NoSQL 데이터베이스 ( http://en.wikipedia.org/wiki/NoSQL )에 적합한 후보로 보입니다 . 그런 데이터베이스를 다루지 않았지만 설명하는 것은 이것이 해결하는 전형적인 시나리오입니다.

사용자 정의 열의 동시 수가 유한하고 한계가 알려진 경우 (예 : 문자열의 경우 10-20 개 이하의 사용자 정의 열, 정수의 경우 x 개 이하)
기본 테이블을 데이터 유형 당 추가 필드와 함께 사용할 수 있습니다. 매년 테이블을 다시 작성하면 관련 사용자 정의 열만 포함하고 해당 연도의 컨텐츠를 반영하도록 일반 필드의 이름을 바꾸는 해당 연도에 대한보기를 작성합니다.

House Table:
ID, Addr, City, State, Zip, custom_string1,cs_2,cs_3,custom_integer_1,ci_2,ci_3 ...

create view house_2014 as 
select ID, Addr, City, State, Zip,
custom_string1 as last_name,cs_2 as first_name ...

이 방법의 문제점은 기록이 없지만 열 요구 사항을 변경하기 전에 매년 쉽게 사본을 만들 수 있다는 것입니다.

create table house_2014_archive as select * from house_2014;
drop house_2014;
create view house_2015 as "select column list for new year";

이 데이터를 저장하려는 모든 시나리오를 열거 할 수 있습니까?

테이블에 적용될 수있는 제한된 수의 열 조합이있는 경우 모든 시나리오에 적용 할 수있는 공통 열로 "기본 테이블"을 모델링 한 다음 더 많은 테이블을 작성하십시오 (일종의 상속 구현). 이를 ERD 및 데이터베이스 디자인에서 하위 유형 / 수퍼 유형이라고합니다.)

각 시나리오에 대해 하나의 테이블을 사용하면 최소한 이렇게하면 테이블을 깨끗하게 유지할 수 있으며 "성"열에 주소를 저장하지 않아도됩니다.

이 디자인 질문을 살펴보십시오 : https : //.com/questions/554522/something-like-inheritance-in-database-design