모든 데이터베이스에는 차원 및 팩트라는 두 가지 종류의 테이블이 있습니다.

1. 치수는 구성 테이블입니다. 이러한 테이블은 자주 변경되지 않으며 일반적으로 단일 현재 스냅샷 값입니다(일부 기록 변경이 있을 수 있음 - 아래에 자세히 설명됨). 가장 일반적인 작업은 테이블에 대한 편집입니다. 이를 구성 또는 마스터로 생각할 수도 있습니다.
2. 팩트는 시간에 따라 거의 선형적으로 증가하는 표입니다. 일반적으로 이러한 엔터티는 시간이 지남에 따라 정기적으로 생성되며 생성된 사실에 대한 업데이트는 일반적이지 않으며 일반적으로 더 많은 컨텍스트를 위해 차원을 참조합니다.

데이터베이스 스키마를 설계할 때 다음 지침 중 일부는 올바르게 수행하는 데 도움이 됩니다.

노멀 퍼스트

데이터베이스가 SQL인지 NoSQL인지에 관계없이 엔티티/객체 및 테이블을 정규화된 스키마 관점에서 한 번 생각하는 것이 유용합니다. 정규화된 스키마는 엔터티, 관계 및 필드에 대한 명확성을 제공합니다. 이것으로부터 NoSQL로의 비정규화 또는 변환은 간단할 수 있으며 의식적인 설계일 수 있습니다.

실제 엔터티 미러링

사용 사례/보고서가 불분명하더라도 스키마 엔티티는 실제 사용 사례를 반영해야 합니다. 이러한 스키마는 일반적으로 강력합니다.

다음 중 하나는 일반적으로 다른 엔터티 및 테이블을 식별하고 생성하는 경우입니다.

1. 서로 연결되지 않고 독립적으로 & 잠재적으로 존재할 수 있는 논리적으로 분리된 엔터티(예: 데이터 세트 및 스테이션)
2. 서로 다대다 관계 또는 일대다 관계를 맺습니다. 예를 들어 전자 상거래 회사, 주문 및 고객의 경우입니다.

쿼리, 검색 또는 정렬에 사용되는 필드가 있는 경우 기본적으로 해당 필드에 대한 인덱스를 추가합니다. 이점이 최대이므로 기본적으로 이러한 필드에 대해 간단한 인덱스가 켜져 있어야 합니다. 인덱스를 추가하지 않는 것은 기본 상태가 아니라 의식적으로 선택해야 합니다.

올바른 필드 유형 사용

1. 옵션 값의 고정 세트가 있는 필드에 대한 열거형 대 문자열 유형: 열거형은 바이트로 구현되므로 공간을 덜 차지합니다(예: 1–4바이트 길이의 바이트/긴/정수 vs 128바이트 문자열). 검색합니다. 큰 테이블의 경우 공간 및 성능 요구 사항이 합산됩니다. 기본적으로 열거형을 사용합니다.
2. 기본 키(ID) 유형: 성능 및 저장 방식 - 고정 크기 키(예: 정수 또는 UUID)를 사용하는 것이 항상 권장됩니다.
3. 공통 테이블 필드: 일부 필드는 변경될 수 있는 모든 ORM 엔터티에서 제안됩니다. 예: created_at, updated_at, created_by, updated_by. 또한 외래 키 연결이 자주 있고 거의 삭제되지 않는 엔터티의 경우 소프트 삭제를 사용하는 것이 좋습니다.

Drishti의 쿼리는 여러 조인을 포함하여 복잡할 수 있습니다. 데이터베이스는 메모리 내 조인 및 계산에 최적화되어 있습니다. 가능하면 ORM 계층에 대한 추가, 적절한 쿼리 또는 스키마 재설계를 통해 데이터베이스에서 이러한 조인 또는 계산을 실행하십시오. 일반적으로 데이터베이스가 메모리 내에서 수행할 수 없는 경우(예: 데이터베이스 간 조인)에만 응용 프로그램 코드에서 대규모 결과 조인을 살펴봐야 합니다.

히스토리 테이블을 언제 추가합니까?

모든 트랜잭션 기반 시스템에는 주요 엔터티에 대한 모든 변경 사항에 대한 기본 로깅이 필요합니다. API를 통해 구성/수정되기 때문에 이는 특히 Dimension 테이블에 적용됩니다.

다음 두 가지 방법으로 유지 관리할 수 있습니다.

1. 속성 변경에 대한 일반적인 추상화를 유지합니다. 이 변경 기록의 모든 행은 엔터티 유형, 속성, 엔터티 ID, 이전 값 및 새 값을 가리킵니다. 장점: 엔터티마다 새 테이블이 필요하지 않습니다.
2. 값이 변경될 때마다 엔터티별 기록 테이블을 유지합니다. 이점: 여러 필드 변경 사항을 원자 트랜잭션으로 캡처하여 고객에게 그대로 보여줍니다. 따라서 사용자가 프런트엔드에서 또는 다른 방식으로 수행한 트랜잭션의 개념이 유지됩니다.