네이밍 컨벤션

같은 이름을 써도 DBMS마다 저장되는 대소문자는 다릅니다

식별자 규칙은 단순한 표기 취향이 아니라, 생성된 객체 이름이 실제로 어떻게 저장되고 조회되는지에 직접 영향을 줍니다.

실무 기본 규칙

snake_case + 소문자로 통일하고, 꼭 필요할 때만 큰따옴표를 씁니다. 그래야 DBMS를 바꾸거나 운영체제가 달라도 이름 해석이 흔들리지 않습니다.

DBMS
따옴표 없이 저장
큰따옴표 사용
왜 주의해야 하나
Oracle 대문자 접힘

기본 식별자는 내부적으로 대문자로 정규화됩니다.

Customer → CUSTOMER
"Customer" → Customer
대소문자 혼용 이름을 유지하면 이후에도 같은 표기로 계속 감싸야 합니다.
MySQL OS 영향

이름 해석이 운영체제 파일시스템 특성과 연결될 수 있습니다.

Linux: 구분

Order와 order를 다르게 볼 수 있습니다.

Windows: 비구분

같은 스키마라도 환경이 바뀌면 이름 충돌 가능성이 생깁니다.

개발과 운영 OS가 다르면 이식성 문제가 바로 드러납니다.
PostgreSQL 소문자 접힘

따옴표 없는 식별자는 내부적으로 소문자로 정규화됩니다.

Customer → customer
"Customer" → Customer
혼합 대소문자 이름을 만들면 조회할 때도 큰따옴표와 정확한 철자를 맞춰야 합니다.
한눈에 보는 결론

Oracle은 대문자, PostgreSQL은 소문자 쪽으로 자동 정리되고, MySQL은 환경 영향이 큽니다. 따라서 팀 규칙은 lowercase snake_case로 고정하는 편이 가장 안전합니다.

큰따옴표는 “원본 유지” 스위치

읽기 편하다고 섞어 쓰기보다, 정말 원본 대소문자를 보존해야 할 때만 제한적으로 사용해야 이후 SQL 작성과 이식성이 단순해집니다.