db의 컬럼 이름과 bean의 이름을 맞춰서 사용하시나요?

Question

저는 my-sql만 사용해봤습니다. my-sql은 특별히 대소문자를 구분하지 않는 것 같습니다. db의 컬럼과 매핑하기 위한 bean을 작성할 때, 보통 명명 규칙은 어떻게 하시나요? 저는 처음에는 db의 컬럼과 bean의 프로퍼티 이름을 완전히 똑같이 했었습니다. private Date regDate가 있다면 db 컬럼도 regDate로 했습니다. 대소문자를 구분하지 않으니 큰 의미는 없습니다만... jsp에서 el에 값을 입력할 때나 서블릿에서 멤버 이름 적을 때, 같은 이름을 사용하니까 db의 컬럼 이름도 잘 기억나고, 굳이 이거에 연관된 컬럼 이름이 뭐였더라? 하는 고민이 없었습니다. 다른 프로그래밍 소스를 보다보니 db의 컬럼 이름을 언더스코어로 구분을 하는 경우가 많은 것 같더군요. regDate -> reg_date 등 (웹서핑 등으로 살펴본 소스들) 그래서, 아... 이게 표준이구나 해서, 최근 소스들을 다시 다 뜯어고치다가 (아마추어다 보니 이런거에 예민합니다) 이게 뭔 짓인가 싶어 갑자기 궁금함이 들었습니다. db의 컬럼 이름을 언더스코어로 할 경우 거시적인 관점에서 어떤 장점들이 있나요? 혹은 카멜표기법을 이용할 경우 어떤 점이 불편할까요? 감사합니다.

redeye0922 · Answer

변수 표기 룰을 어떻게 따르냐 차이 이죠 어떤게 더 불편하다 편하다는 개개인의 차이라고 보여지네요 자기가 사용할때 보다 직관적인게 더 편한것아닐까요??? 또한 다른사람이 봤을때 이해하기 쉬워야되고요

fender · Answer

자바나 SQL이나 각 영역에서 가장 널리 쓰이는 컨벤션을 따르는 것이 좋은 습관이라고 생각합니다. 굳이 변수명을 컬럼명으로 통일하면 자바를 할 때도 데이터베이스 중심으로 사고하게 되는 것 같습니다. 객체지향 언어와 관계데이터베이스 간의 '임피던스 미스매치'는 매우 오래된 난제 중 하나인데, 컨벤션상 변수명을 컬럼에 맞추기 시작하면 데이터베이스에 없는 객체지향적 특성을 점점 사용하지 않고 단순 CRUD 중심의 개발을 하게 되는 위험이 있다고 봅니다. 전 데이터베이스 쪽은 깊게 알지 못하지만 아마도 반대의 경우에도 비슷한 문제가 있을 것 같습니다. 따라서, 레퍼런스가 필요하면 차라리 주석이나 어노테이션을 활용하더라도 굳이 서로 다른 영역의 컨벤션을 억지로 통합할 이유는 없다고 생각합니다.

깽쟈 · Answer

객체지향적 사고방식이 결여되어 단순 CRUD 중심으로 가게될 것이라는 말씀을 듣고보니 고개가 절로 끄덕여집니다. 좋은 의견 감사합니다.

frost73 · Answer

MyBatis의 경우 mapUnderscoreToCamelCase 옵션을 사용하면 Domain 객체(캐멀)를 자동으로 DB컬럼(언더스코어)으로 매핑하여 줍니다. Hibernate의 경우는 Domain객체 생성 시 Annotation으로 DB컬럼명을 명시해주는게 전부입니다. 결국 특별한 경우가 아니면 Java는 캐멀, DB는 언더스코어 사용하시면 됩니다.

db의 컬럼 이름과 bean의 이름을 맞춰서 사용하시나요?

4개의 답변

Q&A 목록