데이터베이스 모델링 1-3 작명(Naming rule)

어떤 DA이건 초기 설계시 우선 세우는 원칙중 하나가 Naming rule 이다.

첫째로 가독성이고 유지보수시 개발 담당자이건 DBA에게 혼선을 줄 수 있기 때문이다.

간단하게 절대적 룰이라고 말할 수는 없으나 개인적 경험치로 말해 보겠다.

중요한건 한눈에 잘 들어오며 패턴이 일정하다는게 중요하다.

MS의 경우 DMV(Dynamic Management Views)에서는 정보를 취득할 수 있으나 SSMS만 보고 작업시 실수하는 경우가 종종 발생한다.

전체적으로 작명은 너무 길지 않되 의미가 한눈에 들어오는게 좋다.

DB 모델링 naming rule

 

※ 스키마명

4자미만(보통 3글자로 사용되며 기본 스키마인 DBO를 참조해서 그러한듯 싶다.)의 고정형 문자로 보통 지정하고 비지니스 타입으로 구분하는게 일반적이며

비지니스가 복잡하지 않는 경우 기준정보/배치/raw data.. 등등으로 구별한다.

 

※ 테이블명 :

테이블명은 복합단어의 경우 크게 언더바와 대소문자를 섞어서 생성한다.

가령 MAT_OUT 혹은 MatOut 으로 표현되며 통일성만 유지하면 된다.

모델링중에는 필수정보와 optional하게 상세정보가 있을 경우 테이블을 분할하게 되는데

이때 구분은 테이블명_head/ 테이블명_desc 으로 통일성을 만들어 주는 경우가 많다.

히스토리 테이블을 만드는 경우가 종종있으나 기본적으로 별도 생성은 지양한다.

raw data를 가진 테이블 자체가 히스토리가되는 경우가 대부분이며 보통의 경우 테이블이 비대해질 우려가 있을 경우 예상되는 조회 조건(보통은 일자(시))으로 파티션 테이블로 생성하며 사용유무를 가리키는 컬럼(보통 Y/N)으로 구분하게 된다.

 

※ 컬럼명 :

테이블명은 패턴을 전체적으로 일치시키되 DBMS내에서 지원되는 함수/메서드/속성 의 명칭과 동일하지 명명한다.

 

※ 트리거 :

DDL 트리거 : TR_DDL_상세

테이블 트리거 : TR_ 테이블명_(INS, UPT, DEL, EXE(모두)

 

※ Programmability :

스토어드 프로시저 : SP_비지니스명

스칼라함수 : F_비지니스명(테이블 리턴인 경우 _TBL을 추가)

타입 : TYP_비지니스명 (테이블 타입인 경우 _TBL을 추가)  

 

※ VIEW :

Normal : V_비지니스명

Indexed View : IV_비지니스명

 

※ 시퀀스 : SEQ_테이블명_컬럼명( 스키마 사용시 테이블명 -> 스키마명_테이블명)

 

※ 제약조건 : 스키마 사용시 테이블명 -> 스키마명_테이블명

PRIMARY KEY : PK_테이블명 : 간혹 noncluster형 pk인 경우는 PK_테이블명_NC
FOREIGN KEY : FK_ 자식테이블명_자식컬럼명_ 부모테이블명_부모컬럼명

UNIQUE : UQ_테이블명 _컬럼명
DEFAULT : DF_테이블명_컬럼명
CHECK : CK_테이블명_컬럼명

 

※ 인덱스 : 스키마 사용시 테이블명 -> 스키마명_테이블명

일반(NONCLUSTER) 인덱스 : IX_테이블명_번호(2자리)

클러스터 인덱스(테이블당 1개이므로 넘버링 필요없슴) : CIX _테이블명

UNIQUE 인덱스 : UIX _테이블명

FILTERED 인덱스 : FIX_ 테이블명_번호(2자리)

 

※ 변수

파라미터형(parameter의 P) : @P_

내부형(variant의 V) : @V_

 

※ 예제

CREATE TABLE DBO.TEST_P (

     IDT INT           NOT NULL

   , NM  NVARCHAR(100)     NULL

   , CONSTRAINT PK_DBO_TMP_P PRIMARY KEY CLUSTERED(IDT)

);

 

/* CREATE TABLE 제약조건 Naming  예제 */

CREATE TABLE DBO.TMP_C (

      IDT        INT      NOT NULL

    , PARENT_IDT INT      NOT NULL

    , USE_YN     CHAR(1)  NOT NULL

    , CR_DATE    DATETIME NOT NULL CONSTRAINT DF_DBO_TMP_C_CR_DATE DEFAULT GETDATE()

    , CONSTRAINT PK_DBO_TMP_C PRIMARY KEY CLUSTERED(IDT)

    , CONSTRAINT CK_DBO_TMP_C_USE_YN CHECK (USE_YN IN('Y', 'N'))

    , CONSTRAINT FK_DBO_TMP_C_PARENT_IDT FOREIGN KEY (PARENT_IDT) REFERENCES DBO.TEST_P(IDT)

);

 

/* ALTER TABLE 컬럼추가시  제약조건 Naming  */

ALTER TABLE DBO.TMP_C ADD TEST_COL VARCHAR(16) NOT NULL

CONSTRAINT DF_DBO_TMP_C_TEST_COL DEFAULT '' WITH VALUES;

 

/* 잘못된 예 */

CREATE TABLE DBO.TEST_FAULT (

     IDT INT           NOT NULL

   , NM  NVARCHAR(100)     NULL

   , PRIMARY KEY(IDT)

);

 

SQL SERVER가 자동으로 유니크(랜덤한 문자로 ㅠㅠ)한 작명을 해주지만 비슷비슷한 테이블이나 컬럼명의 길이가 긴 경우 구분하기 어려울 수 있다.

테이블이 인덱스가 다 그거고 변수가 더 그거지 라고 넘어가도 좋다.

일단 잘 몰라도 패턴을 지키는게 좋다.

계속 강좌가 이어진다면 혹은 당신이 실전에서 삽질을 크게 한번 하고 나서 느낄 수도 있다.

이런 저런 이유로 초기 설계시 귀차니즘의 강한 유혹에 노출되는 경우가 다반사고 충분히 이해는 할 수 있다.

그럼에도 불구하고 개발 기간의 압박을 잘 설득해서 이겨내는 것이 비용 측면에서도 유리할 것이다.

 

이 글은 이비니어스( www.evinious.co.kr )의 소유이며 불펌은 허락하지 않습니다