여러 값을 가진 엔티티에 가장 적합한 디자인

Question

자세한 정보를 캡처하는 차량과 같은 엔티티가 있다고합시다. 당신이 붙잡고 자하는 차는 빨강, 검정, 흰색으로 그려져 있습니다. 앞 타이어는 Bridgestone 275/35-18이고 뒷 타이어는 325/30-19입니다. 그리고 때로는 단지 두 개의 타이어를 가질 수 있습니다 (예 : 자동차의 한 종류 인 오토바이로 간주됩니다). 때로는 18 개의 타이어가 모두 다를 수 있습니다. 그렇다면 엔진 크기와 같이 항상 단일 값을 갖는 필드가 있습니다 (우리가 상상력을 뛰어 넘는다면 우리는 다중 엔진 차량을 생각할 수 있지만 이것을 간단하게 유지하려고합니다).

이 문제를 해결하기위한 현재 전략은 여러 값을 가질 수있는 각 입력란에 대한 표를 사용하는 것입니다. 이것은 많은 수의 테이블을 생성 할 것이고 (우리는이 요구 사항을 가진 여러 엔티티들을 가지고있다.) 약간의 냄새가 난다. 이것이 최선의 전략인가요? 그렇지 않다면 무엇이 더 좋을까요?

Answer 1

앱의 가능성이있는 경우 couchdb을 조사하고 싶을 수 있습니다.

Answer 2

당신은 Star Schema을 설명합니다. 귀하의 종류의 사례에서 상당히 표준적인 방법이라고 생각합니다.

편집 : 실제로 스키마가 별표 스키마에서 약간 수정되었으므로 각각의 차원 테이블에서 사실 테이블의 기본 키를 사용하여 가입 할 수 있습니다. 여러 가지 페인트 색상 등. 어느 쪽이든 그것은 당신의 실체를 다루는 훌륭한 방법이라고 생각합니다. 한 단계 더 나아가 치수 표를 표준화 한 다음 Snowflake Schema

Answer 3

Hierarchical Model이 표시 될 수 있습니다.

어쩌면 (attr, value) 쌍의 간단한 목록이 가능합니까?

Answer 4

SQL Server를 사용하는 경우 XML Data Type을 저장하는 것을 두려워하지 마십시오. 나는 그것이 많은 것을 훨씬 더 쉽게 만들어 준다는 것을 발견했다.

Answer 5

실제로 변수 자체에 하나의 변수 만 있는지 여부에 달려 있습니다 (예 : 가변 개수의 타이어가 모두 동일한 유형이거나 설정된 수의 타이어가 가변 유형 일 수 있음).

변수가 여러 개인 경우 (예 : 각 타이어에 대해 특정 유형, 가변 개수의 타이어 사용) 가장 좋은 해결책은 원하는 자동차의 특정 영역마다 특정 테이블을 만드는 것입니다 맞춤 설정할 수 있습니다.

사용자가 정의한 값 집합 (예 : 2, 4 또는 6 개의 창)이있는 필드가있는 경우 열거 형을 사용하거나 사용자 정의 도메인을 사용하여 새 필드 유형을 정의 할 수 있습니다 어느 DBMS를 사용하고 있는지).

Answer 6

관계형 데이터베이스를 사용하는 경우 제안은 거의 유일한 방법입니다. theory of normal forms은 그것에 대해 더 많은 정보를 제공 할 것입니다. Wikipedia에 관한 기사는 상당히 훌륭합니다. 비록 더 높은 표준화 수준에 도달 할 때 까다로운 이론 주제이기 때문에 약간 무겁습니다. 예제는 대부분 상식입니다.

Vehicle 테이블, Color 테이블 및 TyreType 테이블 (British 철자를 유감스럽게 생각하는)이 있다고 가정하면 관련 테이블 쌍 간의 조인 역할을하는 VehicleTyre 및 VehicleColour 테이블을 정의 할 수 있습니다. 이 구조는 실제로 꽤 건강합니다. 그것은 당신이 직접적으로 원하는 정보를 캡슐화할뿐만 아니라 타이어가 어떤 것인지 (예 : 프론트 좌측은 Bridgestone 275/35-18) 또는 차가 빨간색으로 칠해 지는지 (예 : VehicleColour 테이블의 백분율 필드).

타이어 수를 결정할 수있는 차량 유형 엔티티를 모델링하고 싶을 수 있습니다. 이것은 작동중인 SELECT 쿼리를 시스템에서 가져 오기 위해 반드시 필요한 것은 아니지만 사용자 인터페이스와 테이블에 몇 개의 타이어를 삽입할지 파악하는 데 유용 할 것입니다.

우리 회사는 정확하게이 기초 위에서 작동하는 많은 스키마를 가지고 있습니다. 실제로 우리의 객체 관계형 프레임 워크는 다 대다 관계를 관리하기 위해 자동으로 만듭니다 (때로는 우리가 모델하는 방식에 따라 일대 다 관계도 관리합니다). 그들). 우리의 애플 리케이션 중 일부는 150 개 이상의 엔터티와 100 개 이상의 이러한 조인 테이블을 가지고 있습니다. 성능 문제는없고 데이터의 관리 효율성에 유의미한 영향을 미치지 만 몇 가지 테이블 이름이 까다롭기 만합니다.

Answer 7

현재 전략이 올바른 것입니다. 많은 종류의 데이터를 추적하므로 많은 테이블이 필요합니다. 그것이 바로 그 방법입니다. DBMS는 불평하고 있습니까?