먼저 Chapter 1부터 소개를 하자면, 제목이 Data Model Design이다. 저자는 bad data model design을 가진 디비에서 효과적인 SQL을 작성하기는 힘들다고 말한다. 즉, data model이 적절히 정규화되어 있지도 않고 테이블 > 관계도 정확히 설정되어 있지 않은 경우는 효과적인 SQL을 작성하는것이 어렵다.
Item 1 : 모든 테이블이 PK를 가지고 있는지 검증하라.
먼저 위에 제목을 처음읽고 PK를 정의하지 않고, 테이블을 생성할 수 있는 RDB가 있을까 궁금했다. 실제로는 프라이머리 키를 명시해 두지 않더라도, 각 행을 유일하게 구분할 수있는 칼럼들이 있으면 허용되는 경우가 있는것 같다고 한다.
프라이머리 키가 없을때, 많은 문제가 발생할 수 있다. 대표적으로 다음 문제들이 발생할 수 있다.
- 반복되거나 일관적이지 않은 데이터
- 느리게 동작하는 쿼리
프라이머리 키가 될수 있는 좋은 후보는 무엇일까? 고려되는 칼럼들이 다음 성질을 만족해야 한다.
- unique 값들을 포함해야 한다.
- 절대 null이 될수 없다.
- stable 해야한다. (i.e 값을 업데이트 할 필요가 없다.)
- 가능하면 간단해야 한다. (e.g float, character보다는 integer 타입이 낫고 여러 칼럼들 보다는 단일 칼럼들이 낫다.)
Referential Integrity
관계형 데이터 베이스에서 매우 중요한 개념으로, Enforced RI가 의미하는 것은 자식 테이블에 있는 모든 non-null foreign key에 대해서 반드시 부모 테이블에 매칭되는 레코드가 존재해야 함을 의미한다.
테이블들 간의 RI를 유지하기 위해서, PK값의 변경은 반드시 모든 관련된 child record로 cascade 되어야한다. 이러한 업데이트는 관련 테이블에 lock을 걸게 되고 이는 high-cuncurrency multi-user database에 대해서 심각한 문제를 야기한다.
Compound Primary Key
저자들은 compound primary key가 비효율적이므로 추천하지 않는다. 다음의 두가지 이유가 있다.
pk를 정의할때, 데이터베이스 시스템들은 unique index를 가지고 정의를 강요한다. 한개이상의 칼럼을 가지는 unique index는 데이버 베이스에 더많은 일을 하도록 만든다.
단일 pk를 가지고 조인을 수행하는것은 꽤 흔하지만 pk에 있는 여러 칼럼에 대해서 조인하는 것은 더 복잡하고 성능이 느리다.
요약
- 모든 테이블들은 pk로 할당된 칼럼(들)을 가져야 한다.
- non-key 칼럼에 있는 중복 값들에 대해서 걱정이 된다면, 해당 칼럼에 대해서 unique index를 정의할 수 있다.
- key를 가능하면 단순하게 설정하고 업데이트될 필요가 없는 값들을 가진 칼럼으로 설정해라.