Page History
...
어떠한 관계가 형성이되고 인덱스를 설정하는지 파악하는것은 중요한 사안입니다.
| Warning |
|---|
클래스를 통한 어플리케이션에서 테이블 생성전략(DDL)은 일반적으로 개발단계까지 허용이되며, 지속적 빌드및 테스트로 한정지으면단일지점이 아닌, 여러군대를 업데이트해야하는 SP방식보다 분명 유리합니다. 일반적으로 운영에서 어플리케이션이 테이블 구조를 변경하는것은 허용되지 않으며 DDL기능을 off시키고 데이터베이스의 운영및형상을 관리하는 관리자를 통해 하는것이 권장되며, 운영에 자동으로 변영이 되는것은 불안 요소로 측정되거나 금기시 되는 사항입니다. 하지만 이것이 모든경우 항상 옳다라고 할수없으며 해외 잘만들어진 엔터프라이즈급 서비스를 관리하는 어떠한 오픈 소스의 경우에도, 오픈소스 특성상 수많은 개선작업과 데이터구조변경이 여러사람에의해 이루어지며 버젼업이 되었을시, DB구조를 안전하게 변경하면서 버젼업이되는 마이그레이션이되는 패키지를 많이 봐왔습니다. 물론 이것도 장단점이 있으며 분야마다 다른 상황이 존재하지만 현재 운영하는 DB구조를 , 어플리케이션(마이그레이션명령)이 안정적으로 변경하면서 버젼업을 할수 있느냐? 허용하지 않는 정책을 사용합니다. DDL기능을 OFF시키거나, 어플리케이션 내에는 변경 코드 자체가 없을수도 있습니다. DB배포관리자및 DBA에의해 데이터베이스의 운영및 형상을 관리하는것이 일반적입니다. 하지만 어플리케이션 개발자에게 Admin에 준하는 권한을 줘야 개발/운영이 가능한 구조에서 어플리케이션 에게 DDL을 금지하는 정책이 과연 어떠한 의미를 가지는지 고민이 필요해보입니다애시당초 할수없는 구조이기때문에, 여러 관리자와 리소스를 투입해야한다? 기술적인 의미는 다릅니다. |
식별관계 VS 비식별관계
- 식별 관계는 부모 테이블의 기본 키를 자식 테이블로 전파하면서 자식 테이블의 기본 키 컬럼이 점점 늘어난다. 그러면 조인할 때 SQL이 복잡해지고 기본 키 인덱스가 불필요하게 커질 수 있다.
- 식별 관계는 2개 이상의 컬럼을 합해서 복합 기본 키를 만들어야 하는 경우가 많다.
- 식별 관계를 사용할 때 기본 키로 비지니스 의미가 있는 자연 키 컬럼을 조합하는 경우가 많다. 반면에 비식별관계의 기본 키는 비지니스와 전혀 관계없는 대리 키를 주로 사용한다.
- 언제든지 요구사항은 변한다. 식별 관계의 자연 키 컬럼들이 자식에 손자까지 전파되면 변경하기 힘들다.
- 식별 관계는 부모 테이블의 기본 키를 자식 테이블의 기본 키로 사용하므로 비식별 관계보다 테이블 구조가 유연하지 못하다.
...