-
Notifications
You must be signed in to change notification settings - Fork 3
DB 네이밍 컨벤션
“FirstName” 또는 “All Employees” 등의 이름은 대표적인 나쁜 이름의 예시이다.
이름에 따옴표를 사용하면 SQL을 작성하기 어려워진다.
또한 이름에 공백을 포함해서는 안된다.
이 규칙은 테이블, 뷰, 컬럼 및 기타 모든 것이 포함된다. 대소문자가 혼합된 이름은 사용할 때마다 큰따옴표로 묶어야 함을 의미한다.(1번에 위배됨)
데이터베이스 객체 이름, 특히 컬럼 이름은 필드 또는 객체를 설명하는 명사여야 한다. text 또는 timestamp 와 같은 데이터 타입의 이름을 사용하면 안된다.
여러 단어로 구성된 객체 이름의 경우 언더스코어로 구분해야 한다.
ex : wordCount 나 wordcount 대신 word_count를 사용한다.
객체 이름은 완전한 영어 단어로 작성해야 한다.
대부분의 데이터베이스는 최소 30자의 이름을 지원하므로 충분하다.
ex : mid_nm 대신에 middle_name 사용
몇 긴 단어의 경우 약어가 단어 자체보다 더 통용되는 경우가 있다. 이런 경우에는 약어를 사용한다.
ex : Internationalization → i18n , localization → l10n (처음 들어봄;;)
사용중인 데이터베이스에서 예약어로 간주되는 단어는 사용하지 않는다.
예약어를 이름에 사용하면 따옴표를 붙여줘야 할 수 있다. (1번 위배)
ex : user, locak, table 등을 이름으로 사용하지 않는다.
데이터를 보유하는 테이블, 뷰 및 기타 관계는 복수형이 아닌 단수형 이름을 가져야 한다.
예를 들어 팀에 대한 테이블의 경우 teams가 아닌 team으로 이름을 지정해야 한다.
단수로 지정해야 하는 이유는 다음과 같다.
일관성 : 단일 행을 보유하는 관계를 가질 수 있다.
분명하다 : 단수 이름을 사용하면 명사를 복수화하는 방법을 고민할 필요가 없다. (ex : Person의 경우 복수 이름을 사용하면 Persons로 지을지 People로 지을지 결정해야 한다. Octopus 는 Octopuses, Octopi, Octopodes 등)
프로그래밍 언어와 데이터베이스 간 변환이 간단하다. : 단수 이름을 사용하면 프로그래밍 언어와 DB 간의 이름 변환이 간단히 적용된다.
기본 키 필드의 이름은 id로 작성한다. 짧고 간단하며 모호하지 않다.
일부 가이드에서는 기본 키 필드에 테이블 이름을 접두어로 추가할 것을 권장한다. (ex : person_id) 그러나 SQL 문에서 필드 이름은 명시적으로 수식되어야 하므로 네임스페이스 형태로 접두사를 붙이는 것은 좋지 않다.
외래 키 필드는 참조된 테이블의 이름과 참조된 필드의 이름 조합이어야 한다.
아래는 team과 person 테이블을 참조한 외래 키 이름의 예시이다.
CREATE TABLE team_member (
team_id int NOT NULL REFERENCES team(id),
person_id int NOT NULL REFERENCES person(id)
CREATETABLE team_member ( team_id intNOTNULLREFERENCES team(id), person_id intNOTNULLREFERENCES person(id)
아래 3가지 접두사 또는 접미사 유형은 모두 나쁜 사례이다.
일부 지침에서는 테이블 이름에 “TB_”, 뷰의 이름에 “VW_”와 같은 접두사를 제안한다. 처음보는 SQL을 읽는 프로그래머가 이름을 기반으로 타입을 알 수 있다는 근거인데, 이 것은 나쁜 생각이다.
개체 이름에는 개체 유형이 포함되어서는 안된다. 그래야 나중에 개체를 변경하기 수월하다. 뷰가 어느 시점에서 테이블이 되는 경우가 있는데, 접두사를 붙이면 필드명을 변경해야 하므로 변경 후에 종속된 시스템들을 수정해야 한다.
모든 데이터베이스 객체에 대해 공통 접두사를 사용하는 것이다. 예를 들어 Foobar라는 앱에서 사용하는 테이블 이름 앞에 앱의 이름을 접두사로 사용하는 것이다. (Foobar_users, Foobar_teams) 이 방법은 옳지 않다.
모든 최신 데이터베이스는 어떤 형태의 네임스페이스를 지원한다. 예를 들어 PostgreSQL에서 스키마를 생성하여 데이터베이스 객체를 그룹화할 수 있다. 동일한 데이터베이스를 공유하는 여러 애플리케이션이 있고 서로 방해하는 것을 방지하려면 대신 스키마를 사용하면 된다.
이 규칙의 예외는 프레임워크나 플러그인과 같은 데이터베이스에 구애받지 않는 코드 기반을 개발하는 경우이다. 그러나 대부분 사람들은 플러그인이나 프레임워크가 아닌 응용 프로그램을 개발하므로 모든 데이터베이스 객체 이름에 접두사를 추가할 이유가 없다.
일부 가이드(일반적으로 오래된 가이드)에서는 필드의 데이터 타입으로 컬럼 이름에 접미사를 추가할 것을 제안한다. 예를 들어 텍스트 타입의 이름 필드인 경우 name_tx와 같다. 이것은 나쁜 방법이다.
필드 데이터 타입은 변경될 수 있다. Date는 TimeStamp가 될 수 있고 int는 bigint 또는 numeric으로 변경될 수 있다.
데이터베이스 객체를 만드는 일부 데이터베이스 명령은 이름을 지정할 필요가 없다. 객체 이름은 무작위 또는 규칙을 통해 생성된다. 이름이 생성되는 방법을 정확히 알지 못하므로 명시적으로 이름을 지정해야 한다.
인덱스는 명시적으로 이름을 지정해야 하며 인덱싱된 테이블 이름과 컬럼 이름을 모두 포함해야 한다.
자동으로 생성된 foobar_ix1 과 같은 인덱스 이름은 한눈에 이해하기 어렵다.
CREATE TABLE person (
id bigserial PRIMARY KEY,
email text NOT NULL,
first_name text NOT NULL,
last_name text NOT NULL,
CONSTRAINT person_ck_email_lower_case CHECK (email = LOWER(email)));
CREATE INDEX person_ix_first_name_last_name ON person (first_name, last_name);
CREATETABLE person ( id bigserial PRIMARY KEY, email text NOTNULL, first_name text NOTNULL, last_name text NOTNULL, CONSTRAINT person_ck_email_lower_case CHECK (email =LOWER(email))); CREATE INDEX person_ix_first_name_last_name ON person (first_name, last_name);
위와 같이 person_ix_first_name_last_name 라는 이름으로 인덱스를 생서앟면 person 테이블의 이름과 성에 대한 인덱스라는 것을 이해하기 쉽다.
인덱스와 유사하게 제약 조건도 설명적인 이름을 지정해야 한다.
위반된 제약 조건이 발생하면 잘못된 삽입을 확인하는 것이 훨씬 쉽다.
CREATE TABLE team (
id bigserial PRIMARY KEY,
name text NOT NULL);
CREATE TABLE team_member (
team_id bigint REFERENCES team(id),
person_id bigint REFERENCES person(id),
CONSTRAINT team_member_pkey PRIMARY KEY (team_id, person_id));
CREATETABLE team ( id bigserial PRIMARY KEY, name text NOTNULL); CREATETABLE team_member ( team_id bigintREFERENCES team(id), person_id bigintREFERENCES person(id), CONSTRAINT team_member_pkey PRIMARY KEY (team_id, person_id));
Welcome STANL2 Final Project Document!😁