데이터베이스 질문과 답변
by llgxj [Oracle 기초] [2024.05.28 09:00:12]
회사 전산실에서 sm만 오래하다가(회사자체가 일반 sm성격은 아닌 si성향) 도전하러 새로운 구축프로젝트하러 회사에 입사했는데요 프로젝트 PL을 하게 되서 업무파악하고 디비 설계를 하고 있습니다.
그런데 전 키가되야되는 것들을 TABLE에 PK로 다 잡으려고 합니다.
EX) 회사코드, 거래처코드, 거래처코드구분1,거래처구분2, 부서코드, 관리코드(이게 유니크키라고 볼수 있음)
그런데 다른분들은 그냥 회사코드에 관리코드 만 키로 잡으면 되는거 아니냐 PK를 많이 가져가지 말자는 식으로 이야기를해서 제가 SM만 해서 요즘 트렌드를 잘몰라서 그런건지 한번 다들 현업에서 어떻게 구성하시는지 궁굼합니다.
유니크한 컬럼이 있다면 그것으로만 키를 잡아도 충분하지 않을까요?
적어도 제가 프로젝트 할때는 최소한의 컬럼을 PK로 잡고, 조회에 사용되는 컬럼 정도를 INDEX 로 따로 잡아주는 형태로 작업했었습니다.
1. Unique 해야 한다.
2. Minimum set 이어야 한다.
3. 업무에서 자주 사용하는 후보키를 PK로 선정한다.
4. 손자테이블에서 할아버지테이블을 바로 조인할 경우
할아버지-부모-손자 로 PK를 상속(?)한다.
5. 항상(자주) 사용하는 컬럼을 PK컬럼의 선두로 구성한다.
해당 테이블이 어떤 테이블인가요?
뭔지 잘 모르겠지만 많아 보이긴 합니다.
이 많은 항목이 필요한 이유나 테이블의 특성을 설명할 수 있어야 합니다.
업무기본이 되는 테이블 입니다.
계약 하기전에 마스터관리를하는.
그렇게 간단하게 설명하시면
이 PK 가 맞는지 틀린지 판단 할 수가 없죠.
이 PK 가 맞다는 걸 설명을 통해 납득시킬 수 있어야 합니다.
실질적으로는 회사, 거래처, 부서, 거래처유형, 거래처유형 상세가 유니크 해야됩니다. 그래서 저는 다 pk로 잡을려고하는거고요
그런데 key_code라고 한게 내부적으로 seq처럼 pk로 구분하는 컬럼 만들고 거래처유형, 거래처유형상세를 그냥 속성으로 가져가고 프로그램에서 체크해서 처리하자는거 같습니다.
회사, 거래처, 부서, 거래처유형, 거래처유형 상세가 유니크 해야 하는 당위성을 증명하셔야 합니다.
그냥 그래야만 합니다 라고 정하는게 아니라
왜 그래야 하는지를 증명하셔야 합니다.
동료분들은 안그래도 될 것 같은데? 라는 분위기 인듯 하네요.
PK 컬럼이 많아지면 SQL 작성 시 조인을 위해 많은 컬럼을 사용해야 하고 프로그램 만들 때도 코딩이 길어지는 문제가 있을 수 있습니다.
반면 데이터 조회 시 별도의 인덱스 없이도 PK 인덱스만으로도 데이터를 조회해 올 수 있을 것이고 별도의 유니크 제약 없이 데이터 정합을 지킬 수 있을 것입니다.
어떤 게 더 좋은 설계다 하는 기준은 없습니다.
시스템과 업무를 잘 아시는 분들과 상의하셔서 결정하셔야 할 것 같네요.
) 버튼을 클릭하여 작성 하시면 됩니다.