레코드 메타 데이터 저장을위한 모범 사례

데이터베이스에 개별 레코드의 메타 데이터를 저장하는 가장 좋은 방법은 무엇입니까?

데이터베이스의 많은 테이블에 대한 생성 시간 및 마지막 업데이트 시간과 같은 일반적인 메타 데이터를 저장해야합니다. 몇 가지 다른 해결책을 찾았습니다.

1. 메타 데이터를 테이블에 직접 저장하십시오.

   장점 :

   • 메타 데이터는 레코드에 직접 연결됩니다
   • 메타 데이터를 검색하는 데 조인이 필요하지 않습니다.

   단점 :

   • 상속이 사용되지 않는 한 많은 중복 열이 필요합니다.
   • 메타 데이터와 비즈니스 데이터는 분리되지 않습니다

2. 소프트 외래 키를 사용하여 일반 메타 데이터 테이블을 작성하고 데이터를 올바른 테이블 및 레코드에 링크하십시오.

   장점 :

   • 열 중복 없음
   • 메타 데이터는 비즈니스 데이터와 분리됩니다

   단점 :

   • 메타 데이터와 데이터간에 직접 링크가 없습니다 (FK는 사용할 수 없음)
   • 조인에는 추가 조건이 필요합니다

3. 메타 데이터가 필요한 각 테이블에 대해 개별 메타 데이터 테이블을 작성하십시오.

   장점 :

   • 메타 데이터는 레코드에 직접 연결됩니다
   • 메타 데이터는 비즈니스 데이터와 분리됩니다

   단점 :

   • 추가 테이블이 많이 필요합니다
   • 상속이 사용되지 않는 한 많은 중복 열이 필요합니다.

여기에 언급 한 것보다 더 많은 옵션, 장단점이 있습니까? 이 메타 데이터를 저장하는 가장 좋은 방법은 무엇입니까?

당신이 말하고있는 열은 20 바이트를 차지 합니다 (패딩없이 정렬 된 경우).

생성 시간, 업데이트 시간 및 생성 소스

타임 스탬프 .. 8 바이트
타임 스탬프 .. 8 바이트
정수 .. 4 바이트

별도의 테이블에서만 별도의 행에 대한 튜플 헤더 및 항목 포인터는 23 + 1 + 4 = 28 바이트 + 실제 데이터 20 바이트 + 끝에 4 바이트의 패딩을 차지합니다. 행당 52 바이트를 만듭니다 . 더 많은 것을 읽으십시오 :

• 읽기 성능을 위해 PostgreSQL 구성

스토리지에 관해서는 얻을 것이 없습니다. 성능과 관련하여 행당 16-24 바이트 만 있으면 아무것도 잃지 않습니다.

열은 또한 행에 직접 속해 있으므로 함께 유지하는 것이 좋습니다. 모든 관련 테이블에 정확히 이러한 열 (마지막 업데이트의 별도 소스)을 추가하는 것이 습관입니다.

또한 TRIGGER ON INSERT OR UPDATE최신 상태를 유지하기 위해 를 작성하는 것이 더 쉽습니다 .

간단히 말해 : 귀하의 선택에 대한 강력한 투표 1 .

옵션 3으로 갈 곳 :
메타 데이터가 자주 업데이트되는 경우 핵심 행은 업데이트되지 않습니다. 그런 다음 별도의 1 : 1 테이블을 유지하여 UPDATE를 저렴하게 만들고 기본 테이블의 부풀림을 줄이거 나 옵션 2로 이동하십시오.

옵션 2 로 이동하는 위치 :
메타 데이터 열 세트가 매우 반복적 인 경우. 기본 테이블의 메타 데이터 세트에 FK 열이있을 수 있습니다. 귀하의 예와 같이 세 개의 작은 열에 대해서는 크게 절약하지 않습니다.