로그 테이블에 id 필드 또는 기본 키가 있어야합니까?

특정 파일을 다른 시스템으로 내보낼 때의 날짜 시간 스탬프를 캡처하는 로그 테이블이 있습니다.

내 보낸 로그 테이블에는 현재 세 개의 필드가 있습니다.

id                (primary key)
messageId         (int)
exportedDateTime  (datetime)

이것을 검토 한 결과이 id테이블에 조인이 없기 때문에 해당 필드가 아무 목적이없는 것으로 나타났습니다 . 이 테이블에서 작업하는 유일한 것은 메시지를 처리하고이 로그 테이블에 삽입하는 배치 작업 삽입입니다.

id필드를 제거해야합니까 ?

나도에 기본 키가 있어야 messageId하거나 exportedDateTime또는 둘 모두를?

id 필드를 제거해야합니까?

나는 그것을 유지하는 것이 좋습니다.

현재 필드가 필요하지 않을 수도 있지만 나중에는 실제로 도움이 될 수 있습니다. 각 로그 항목에 대한 파일 세부 정보를 저장해야하는 경우 어떻게해야합니까?

이 테이블의 크기와 속도를 모르지만 큰 테이블에 열을 추가하는 것은 일반적으로 비용이 많이 드는 작업입니다. 테이블이 상대적으로 작 으면 저장 공간 측면에서 유지하는 것이 그리 중요하지 않습니다. IMO, 컬럼을 유지하고 나중에 두통을 예방하십시오.

messageId 또는 exportDateTime 또는 둘 다에 기본 키가 있어야합니까?

messageId이 테이블에서 독특하다고 생각 되지는 않지만 (잘못 될 수도 있지만) 날짜 / 시간 열에 고유성을 만들면 중복 (및 오류)이 발생할 수 있습니다. 왼쪽에있는 유일한 옵션은 2 열 키이며, 위에서 설명한 시나리오를 고려할 때 특히 매력적이지 않습니다.

본질적 으로이 답변의 요점은 칼럼 을 유지 하는 것이 큰 문제가 아니라고 가정하지만 나중에 필요하면 큰 문제가 될 수 있으며 추가 작업이 필요합니다.

• 이 테이블에 조인이없고 업데이트 및 삭제가 없으면 키가 전혀 필요하지 않습니다.

• 이것이 사실이 아니며 messageId고유 한 경우 기본 키로 만들 수 있습니다.

• 고유하지는 않지만 (messageId, exportedDateTime)복합 기본 키로 만듭니다.

• (messageId, exportedDateTime)조합으로 도 복제 가 가능하고 실수로 삽입 된 행을 제거하는 등의 삭제 및 업데이트가 필요할 수있는 경우 id필드를 그대로 두는 것이 좋습니다 .

기본 키는 아프지 않습니다 ... 로그 / 감사 추적의 목적을 고려하면 나중에 문제를 해결하거나 데이터를 복원하는 데 사용될 수 있습니다 (질의가있을 것입니다). 이러한 종류의 작업을 수행하기 위해 기존의 비 로그 / 감사 테이블.