Skip to content
Dictionary Guide

데이터베이스 코딩 규칙 정리

데이터베이스에서 규칙 정의가 필요한 항목

Section titled “데이터베이스에서 규칙 정의가 필요한 항목”

dictionary-api 저장소의 README.md/마이그레이션 스크립트(src/main/resources/db/migration) 에서 사용 중인 규칙을 기준으로 정리한다.

  1. 데이터베이스 접근 권한 발급 규칙
  2. 테이블 네이밍/작성 규칙
  3. 컬럼 네이밍/작성 규칙
  4. 인덱스 네이밍/작성 규칙
  5. 함수/프로시저 네이밍/작성 규칙
  6. 테스트 데이터베이스 규칙
  7. 개발 데이터베이스 규칙
  8. 운영 데이터베이스 규칙

데이터베이스 접근 권한 발급 규칙

Section titled “데이터베이스 접근 권한 발급 규칙”
  1. 데이터베이스 생성 후 애플리케이션 전용 계정을 만들고 해당 데이터베이스에만 권한을 부여한다(grant all privileges on {database}.* to '{user}'@'%' with grant option;).
  2. 모니터링/진단에 필요한 최소한의 전역 권한만 별도로 추가한다(grant process on *.*, grant select on performance_schema.*, grant show databases on *.*).
  3. 권한 변경 후에는 flush privileges;로 반영한다.
  4. 실제 테이블 생성은 계정 발급과 분리한다 — 계정만 만들고, 스키마는 Flyway DDL로 생성한다(테이블 네이밍/작성 규칙 참고).

테이블 네이밍/작성 규칙

Section titled “테이블 네이밍/작성 규칙”
  1. 테이블 이름은 t_{이름} 접두어 + 소문자 스네이크 케이스로 짓는다(예- t_user, t_domain, t_dictionary).
  2. 모든 컬럼에 COMMENT를 붙이고, 테이블 자체에도 ALTER TABLE {table} COMMENT = '...'로 설명을 남긴다.
  3. 엔진은 ENGINE=InnoDB ROW_FORMAT=DYNAMIC을 사용한다.
  4. 등록/수정 감사 컬럼 6개(create_dt/create_user_id/create_ip/update_dt/ update_user_id/update_ip)를 모든 테이블에 동일하게 둔다 — 애플리케이션에서는 AbstractEntity(@MappedSuperclass)가 @PrePersist/@PreUpdate로 자동 세팅한다.
  5. 스키마 변경은 Flyway 마이그레이션(db/migration/{mysql,h2}/{ddl,data})으로만 반영한다. 두 DB 디렉토리는 파일명(버전)을 동일하게 맞추고 문법만 각 DB에 맞게 변환한다.

컬럼 네이밍/작성 규칙

Section titled “컬럼 네이밍/작성 규칙”
  1. 컬럼 이름은 소문자 스네이크 케이스로 짓는다(예- user_eml, use_yn, last_session_id).
  2. 기본키는 {테이블 이름}_id로 짓는다(예- t_user → user_id).
  3. Y/N 플래그 컬럼(use_yn, admin_yn, lock_yn, guest_yn 등)은 VARCHAR(1)이 아니라 **CHAR(1)**을 쓴다 — 값 길이가 항상 고정이라는 의미를 컬럼 타입에 그대로 드러내기 위함이다.
  4. create_user_id/update_user_id는 Flyway로 생성되는 데이터는 1000(SYSTEM)으로, 런타임에 생성되는 데이터는 로그인한 사용자 ID(비로그인이면 1000)로 채운다.

인덱스 네이밍/작성 규칙

Section titled “인덱스 네이밍/작성 규칙”
  1. 고유(unique) 인덱스는 ux_{테이블 이름}_{컬럼 이름} 형식으로 짓는다(예- ux_t_domain_suffix).
  2. 일반 인덱스가 필요해지면 동일한 규칙으로 ix_ 접두어를 사용한다(현재 코드베이스에는 고유 인덱스만 존재한다).

함수/프로시저 네이밍/작성 규칙

Section titled “함수/프로시저 네이밍/작성 규칙”

테스트 데이터베이스 규칙

Section titled “테스트 데이터베이스 규칙”
  1. test 프로파일은 H2(인메모리, MODE=MySQL)를 사용한다 (config/test/application-test.yaml).
  2. 매 테스트 실행마다 새로 기동되어 Flyway 마이그레이션이 처음부터 다시 적용되므로, 체크섬 불일치·outOfOrder 문제와 무관하다.
  3. H2 콘솔(spring.h2.console.enabled)은 test에서만 켜둔다.

개발 데이터베이스 규칙

Section titled “개발 데이터베이스 규칙”
  1. local 프로파일은 개발자 개인 MySQL을 사용한다(config/local/application-local.yaml).
  2. 데이터베이스 접근 권한 발급 규칙대로 전용 계정을 만들고, Flyway DDL(db/migration/mysql/ddl)로 테이블을 생성한다.
  3. 이미 로컬에 적용된 마이그레이션 파일도 자유롭게 수정할 수 있다 — 형상관리 이력이 아니라 개발 초반 단계의 스크립트이기 때문이다. 수정 후 outOfOrder 오류가 나거나 체크섬이 어긋나면 로컬 flyway_schema_history 테이블을 삭제하고 애플리케이션을 재기동해 처음부터 다시 마이그레이션한다.

운영 데이터베이스 규칙

Section titled “운영 데이터베이스 규칙”
  1. prod 프로파일도 별도 DB 서버 없이 H2(인메모리)를 사용한다 — 무료 호스팅에 데모 버전을 올리는 용도이며, 재배포/재시작 시 데이터가 초기화된다.
  2. H2 콘솔은 반드시 꺼둔다(spring.h2.console.enabled: false) — H2 콘솔은 애플리케이션 인가 체계(AuthorizationInterceptor/SecurityConfig)로 보호되지 않아, 켜두면 커밋된 접속정보로 누구나 운영 DB에 인증 없이 접근할 수 있다.
  3. 운영 환경으로 전환(실제 MySQL 등)할 계획이 생기면 local과 동일하게 전용 계정 발급 + Flyway DDL 적용 절차를 따른다.