데이터베이스 디자인 : 복합 키 대안?

Question

데이터베이스 시스템을 구축하고 있으며 테이블 중 하나의 디자인에 어려움이 있습니다.

이 시스템에는 사용자 테이블, 객체 테이블, 항목 테이블 및 비용 테이블이 있습니다.

비용 테이블의 고유 한 레코드는 사용자, 객체, 항목 및 연도에 의해 결정됩니다. 그러나 항목이 다른 경우 같은 해에 여러 레코드가있을 수 있습니다.

계층 구조는 사용자-> 객체-> 항목-> 연도, 항목 당 여러 해당 여러 해, 객체 당 여러 고유 한 항목, 사용자 당 여러 고유 한 객체, 여러 고유 한 사용자로 간다.

비용 테이블을 설계하는 가장 좋은 방법은 무엇입니까?

나는 userID, objectID 및 itemID를 외래 키로 포함한 다음 userID, objecid, itemid 및 costyear로 구성된 복합 키를 사용하는 것을 생각하고 있습니다. 복합 키가 잘못된 디자인이라고 들었지만 복합 키를 사용하지 않기 위해 이것을 구조화하는 방법은 확실하지 않습니다. 당신이 말할 수 있듯이 내 데이터베이스 빌딩 기술은 약간 녹슬 었습니다.

감사!

추신 : 중요한 경우, 이것은 인터베이스 DB입니다.

Answer 1

복합 키를 피하기 위해 대리 키 만 정의합니다. 예를 들어 자동 카운터와 같은 인공 가치가 있습니다.

이 열에서 고유 한 제약 조건을 여전히 정의 할 수 있습니다.

BTW : 복합 키를 사용하지 않는 것이 좋습니다. 대리 키를 사용하는 것이 좋습니다. 모든 테이블에서.

Answer 2

COSTID와 같은 내부적으로 생성 된 키 필드 (대리 키라고 함)를 사용하여 사용자는 절대 보지 못하지만 비용 테이블의 각 항목을 고유하게 식별 할 것입니다 (SQLServer에서는 고유 식별자 또는 Identity와 같은 필드가 트릭을 수행합니다).

Answer 3

정확히 설명한 열을 사용하여 복합 키로 데이터베이스를 구축하고 어떤 일이 발생하는지 확인하십시오. 당신은 즐겁게 놀랄 것입니다. 이 네 열에 누락 된 데이터가 없는지 확인하고 두 개의 행이 네 열 모두에서 동일한 값을 갖지 않도록하면 데이터의 무결성을 보호하는 데 도움이됩니다.

복합 기본 키를 선언 할 때 선언의 열 순서는 dclaration의 논리적 결과에 영향을 미치지 않습니다. 그러나 DBMS가 귀하를 위해 구축하는 복합 인덱스도 동일한 순서의 열을 갖고 복합 인덱스의 열 순서가 성능에 영향을 미칩니다.

이 열 중 1 개, 2 개 또는 3 개만 지정하는 쿼리의 경우 인덱스의 첫 번째 열이 쿼리에 지정되지 않은 열인 경우 인덱스가 쓸모가 없습니다. 쿼리가 어떻게 나에게 곤경에 빠지고 가장 빠르게 실행 해야하는 쿼리가 미리 알고 있다면, 기본 키의 열을 올바른 순서로 선언하는 데 도움이 될 수 있습니다. 드문 상황에서는 2 ~ 3 개의 추가 열 인덱스를 생성하면 업데이트 속도를 늦추는 비용으로 일부 쿼리 속도를 높일 수 있습니다.