DB의 테이블명과 칼럼명을 정할 때 대문자로 할지 소문자로 할지는 상당히 고민되는 부분이다. 명확한 표준은 없지만 최근에는 거의 소문자로 통일되는 추세다. 그 이유를 알아보자.
대문자(UPPER CASE)를 피해야 하는 이유
대소문자 구분 문제
Windows에서는 대소문자를 구분하지 않는 것이 기본값이고, Linux에서는 대소문자를 구분하는 것이 기본값이다. 그리고 이 설정값은 변경이 가능하기도 하다. 이런 변수가 있기 때문에 소문자나 대문자로 통일하는 것이 좋다.
PostgreSQL 같은 경우는 테이블 및 칼럼명을 무조건 소문자로 변환하여 저장한다. 꼭 대문자로 하려면 큰따옴표(")로 감싸야 하기 때문에 일반적으로 소문자 사용이 권장된다.
데이터 정렬 방식(collation)을 대소문자를 구분하도록 설정할 수 있는 DB도 있고, 일부 DBMS 관리 프로그램에서 대소문자 인식이 제대로 되지 않을 수도 있다.
여기까지만 봐도 소문자로 해야 하는 이유가 너무나 많다.
가독성 저하
SELECT id, name, created_date
FROM users;
위 쿼리와 같이 이미 많은 개발자들이 SQL 예약어는 대문자 테이블명, 칼럼명은 소문자로 하는 것이 가독성이 더 좋다고 느끼고 있다. 여러 강의나 자료, 블로그 등을 봐도 대부분 이 방법을 선호하는 것 같다.
ORM/프레임워크와의 통합 문제
대부분의 ORM/프레임워크는 소문자 + 언더스코어(_)를 칼럼명 규칙으로 채택하고 있다. 칼렴명이 대문자라면 문제가 발생할 수 있다.
대문자를 쓰는 경우
Oracle일 경우
Oracle은 PostgreSQL과는 반대로 기본적으로 테이블명과 칼럼명을 대문자로 변환하여 저장한다. 그래서 그런지 오래전부터 대문자로 하는 게 관례로 굳어져 왔다.
그렇다고 하더라도 Oracle의 가격이 비싸기 때문에 다른 DB로 변경하는 경우가 많으므로 소문자+언더스코어(_)로 하는 게 좋을 수 있다.
조직의 네이밍 규칙이 대문자일 경우
이미 잘 돌아가고 있거나 조직의 네이밍 규칙이 대문자일 경우 무리해서 바꿀 필요는 없다.
Oracle을 주로 써왔던 곳이나 오래된 소스를 기반으로 개발하거나 유지보수 하는 곳은 아직도 여전히 대문자가 많고, 대부분 대소문자 관련해서는 별 문제 없이 잘 쓰고 있다.
절대 하지 말아야 할 실수
대소문자 혼용
일관성이 파괴된다. 가독성도 안 좋아지고, 예상치 못한 문제가 생길 수도 있다.
결론: 소문자+언더스코어(_)를 기본으로 하자.
소문자+언더스코어(_)로 하는 게 가장 대소문자 관련 이슈를 최소화할 수 있는 방법이고, 프레임워크나 ORM과의 통합, DB 변경 등에도 유연하게 대응할 수 있다. 계속 소문자+언더스코어(_)라고 했는데 스네이크 케이스(snake case) 라고도 한다 . 프로그래밍 언어에서는 카멜 케이스(camel case)가 거의 표준이 된 것처럼 SQL에서는 스네이크 케이스(snake case)가 표준이 되어가는 중인 것 같다.