Skip to content

Latest commit

 

History

History
67 lines (35 loc) · 2.46 KB

column_name_rule.md

File metadata and controls

67 lines (35 loc) · 2.46 KB

데이터베이스 이름의 중요성

이름은 오랫동안 사용된다.

데이터는 애플리케이션에 비해 오랫동안 사용되기 때문에 오랫동안 사용된다.

그렇기 때문에 오랫동안 알기 쉬울만한 이름으로 하는것이 좋다.

이름은 계약이다.

한번 정한 컬럼 이름을 수정하게 되면 해당 데이터베이스와 연결된 애플리케이션에서 또한 수정해야 한다.

즉, 복잡하니 최대한 변경될 일이 없도록 하자

개발자 환경의 차이

테이블, 뷰, 컬럼의 이름이 잘 정리되#어 있다면 다른 개발자들이 쉽게 알아볼 수 있을 것이다.

이름의 규칙

소문자

예약어들과 구분하기 위해 모두 소문자를 이용하는것이 좋다.

꼭 지켜야 하는 규칙은 아니지만 데이터베이스의 예약어 들은 대문자, 이름은 소문자로 해서 구분을 쉽게 하는 관습이 있다.

name_test_one이 Name_test_one이나 Name_Test_One 과 같은 형태보다 낫다.

데이터 타입은 이름에서 빼자

description_text와 같이 데이터의 타입을 컬럼 이름에 넣는것은 좋지 않다.

타입이 변경될 수 있는데, 그럴때마다 컬럼의 이름을 수정하는것은 연결된 애플리케이션에서 부담이 된다.

축약어를 출이자

예를 들어, like_cnt 라는 컬럼보단 like_count 라는 컬럼이 더 낫다.

대부분의 데이터베이스는 30자 이상의 긴 이름을 지원한다.

단수 명사로 쓰자

아무리 1:N 관계든 뭐든, teams나 members 라는 테이블 이름이 아닌 team이나 member 이라는 테이블 이름이 좋다.

이름이 혼란스러울 수 있기 때문이다.

키 필드의 이름

PK

PK의 이름은 다른걸로 할 수 있지만, id가 가장 간편하고, 짧고, 단순하기 때문에 좋다.

몇몇 가이드에서는 테이블명_id 를 권장한다고 한다.

하지만 굳이 테이블명을 반복해서 적을 필요는 없기 때문에 id가 가장 간편하고 통일감 있다.

FK

FK의 이름은 참조테이블_id가 가장 좋다.

가장 단순하며, 알아보기 쉽기 때문이다.

Prefix & Suffix

옛날 가이드라인에선 Prefix나 Suffix에 _table, _view 와 같이 테이블과 뷰를 구분하기 쉽도록 이름을 짓는게 좋다고 했다.

하지만 뷰를 테이블로 전환하려 하면 SQL 쿼리 등 수정할 부분이 많기 때문에 별로라고 한다.