데이터베이스 설계 - 날짜를 기본 키의 일부로 사용해야 합니다.

데이터베이스 설계 - 날짜를 기본 키의 일부로 사용해야 합니다.

기본 키의 일부로 날짜 필드를 포함하는 경우의 장단점은 무엇입니까?

부품 인벤토리 표를 예로 들어 보겠습니다. 재고 수준을 매일 끝에 저장하려면 part_id와 date_of_day에 있는 복합 기본 키를 사용하면 됩니다.이 키를 고유한 키로 만들고 가상 기본 키를 추가할 수 있습니다. 특히 외부 키 제약 조건으로 이 키를 참조하는 테이블이 하나 이상 있는 경우에는 문제가 없습니다.

따라서 반드시 잘못된 것은 아니지만 다른 방법과 마찬가지로 패트릭의 예처럼 잘못 사용될 수 있습니다.

편집: 추가할 다른 의견이 있습니다.

데이터베이스의 날짜 값이 정말 자연스러운 것인지 합성적인 것인지에 대한 주제로 얼마 전에 쓴 글이 생각납니다.날짜를 "YYYY-MM-DD"로 읽을 수 있는 표현은 당연하지만, Oracle 내부에서는 Oracle에 대한 특정 날짜/시간만 나타내는 숫자로 저장됩니다.내부 값이 특정 날짜 및 시간으로 의미를 잃지 않고 언제든지 내부 값의 표현을 선택하고 변경할 수 있습니다(읽기 가능한 다른 형식으로 또는 완전히 다른 달력 시스템으로).저는 그 근거로 DATE 데이터 유형이 자연 데이터 유형과 합성 데이터 유형 사이에 있다고 생각합니다.

키의 일부가 되는 것은 괜찮지만, PK의 일부가 되는 자동 증분 시퀀스 번호가 있어야 하며, 로컬 시간으로 변환하는 것이 아니라 다운스트림 시스템을 사용하여 데이터베이스에 UTC로 기록되도록 강제해야 합니다.

제가 일했던 시스템은 다른 테이블을 터치할 때마다 Oracle 트리거가 데이터베이스에 기록되도록 하고 sysdate를 시퀀스 번호가 없는 기본 키의 일부로 만드는 것이 훌륭한 아이디어라고 판단했습니다.유일한 문제는 초당 두 번 이상 행을 히트하는 업데이트 쿼리를 실행하면 변경 내용을 기록하는 테이블의 기본 키가 끊어집니다.

이미 '자연스러운' 기본 키를 사용하기로 결정한 경우, 질문: 날짜가 기본 키의 필수 부분인지 여부 - 찬성/반대는 무관합니다!

기본 키의 일부로 날짜를 사용하는 것과 관련하여 몇 가지 질문이 있습니다.

날짜에 시간 부분이 포함되어 있습니까?이것은 시간에 시간대와 일광 절약 시간이 포함되기 때문에 상황을 까다롭게 만듭니다.날짜/시간 값은 변경되지 않지만 쿼리를 기반으로 값을 정렬하거나 검색할 때 예상치 못한 결과가 발생할 수 있습니다.

저는 자연 키(날짜를 사용하는 것과 같은)가 아닌 대리 키(즉, 시퀀스 열을 기본 키로 사용)를 사용하는 것을 매우 믿습니다.

약간의 단점은 다른 식별자들처럼 우아한 핸들이 아니라는 것입니다.

(예: 동료에게 부탁한다고 말하는 것보다 레코드 475663을 보는 것이 조금 더 쉽습니다. 2008-12-04 19:34:02를 볼 수 있습니까?)

또한 다른 로케일에서 다른 날짜 형식에 대한 혼동의 위험이 있습니다.

(예: 2008년 3월 4일 - 2008년 4월 3일 유럽, 2008년 3월 4일 미국)

(항상 별도의 키 열을 사용하는 것이 좋습니다.)

언제나처럼..사정에 따라 다르겠지.

PK에 날짜/시간 열을 포함하는 목표는 무엇입니까?행을 실제로 선택할 필요 없이 레코드에 대한 추가 정보를 제공하기 위한 것입니까?

여기서 예측할 수 있는 주요 문제는 명백한 문제입니다. 즉, UTC 날짜를 사용하십니까? 아니면 현지 날짜를 사용하십니까?날짜가 잘못 해석될 수 있습니까(UTC를 의미할 때 현지 시간을 의미한다고 생각할 수 있습니까)?다른 사람들이 제안한 것처럼, 대신에 대리/복합 키에 이 기능을 사용하는 것이 더 나을 수 있습니까?기본 키 이외의 키 또는 인덱스에서 사용하는 것이 성능에 더 좋을 수 있습니다.

[부록]이러한 개념은 행에 의미 있는 날짜/시간 값을 추가하는 것이 아니라 SQL Server가 인덱스를 더 잘 작성하고 인덱스 재구성을 덜 필요로 하는 PK에 대한 고유 ID를 생성하는 것이었지만 (1) COMB(결합된 GUID)에 대한 이론을 떠올리게 합니다.

[http://www.informit.com/articles/article.aspx?p=25862&seqNum=7 ]

날짜는 자연 키의 일부로서 의미가 있다면 완벽하게 좋은 기본 키가 됩니다.다음과 같은 테이블에서 날짜를 사용합니다.

• holiday_facebook (hol_date date)
• employee_message(sal_id 정수, sal_start_date 날짜)

(위의 대리 사원_salary_id를 추가하면 어떤 의미가 있습니까?)

일부 테이블의 경우 날짜를 사용할 수 있지만 다른 것이 기본 키로 사용됩니다. 예를 들어 다음과 같습니다.

• 호텔_룸_호텔(호텔_레퍼런스)

(room_no, booking_from_date) 또는 (room_no, booking_to_date)를 사용할 수도 있었지만, 참조는 고객과 소통하는 데 더 유용합니다.이러한 제약 조건을 고유한 제약 조건으로 만들 수도 있지만, 실제로는 이러한 제약 조건에 대해 더 복잡한 "중복 없음" 검사가 필요합니다.

주 키의 단독 또는 첫 번째 구성 요소인 날짜는 삽입률이 높은 테이블에서 성능 문제를 야기합니다. (테이블을 자주 재조정해야 합니다.)

날짜당 여러 개가 삽입된 경우 문제가 발생하는 경우가 많습니다.

대부분의 상황에서 저는 이것을 나쁜 냄새라고 생각하고, 그것에 대해 충고하고 싶습니다.

다른 포스터가 지적했듯이 시간대와 지역 주민들과 문제가 생길 수 있습니다.또한 많은 DATE() 함수가 SQL을 혼란스럽게 만들 수 있습니다.

앞에서 언급한 것처럼 일말의 인벤토리와 유사한 경우 "20081202"와 같은 8자 텍스트 필드를 기본 키의 두 번째 부분으로 고려할 수 있습니다.이렇게 하면 시간대 로케일 문제를 피할 수 있으며 필요한 경우 실제 날짜로 변환하기에 충분히 쉽습니다.

기본 키에는 레코드를 고유하게 식별하고 고유성을 적용하는 두 가지 기능이 있습니다.대리 기본 키가 더 이상 작동하지 않습니다.

참고하기 어려울 수도 있습니다._ID + _Date를 복합 PK로 발견했습니다.이 복합 키는 다른 테이블의 참조/FK이기도 합니다.

우선 합성되지 않은 키를 제안하는 _ID가 있어 순전히 혼란스러웠습니다.

둘째, 메인 테이블에 SYSDATE를 사용하여 삽입을 수행했으며, 해당 SYSDATE에 있었던 정확한 시간을 파악해야 했습니다.당신은 그것을 언급할 때 그 안에 있는 시간을 정확하게 할 필요가 있습니다.그렇지 않으면 작동하지 않을 것입니다.

날짜를 기본 키의 일부로 사용하면 테이블의 조인 속도가 상당히 느려질 수 있습니다.저는 대리 키를 선호하고 필요하다면 날짜에 고유 인덱스를 선호합니다.

언급URL : https://stackoverflow.com/questions/341055/database-design-should-a-date-be-used-as-part-of-a-primary-key