하이버네이트로 같은 구조의 entity를 여러개 생성할 경우???

222 views
Skip to first unread message

Young Gyu Park

unread,
May 6, 2010, 10:24:23 AM5/6/10
to Korea Spring User Group

대표적인 예가 게시판이 될거 같네요.

게시판 기본 구조는 다 똑같잖아요. 그래서 이 게시판을 생성할때 마다 기본 template에서 entity의 table 명만 바꾸어서 생성하는 식으로 해서 사용가능한가요?

똑같은 구조를 매번 게시판이 필요할때 마다 생성한다는 것은 너무 비효율적인거 같아서요.

혹시 이런식으로 구현한 오픈 소스나 참고할 만한 자료나 팁 같은게 있으시다면 좀 알려 주세요.

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

Sewon Ann

unread,
May 6, 2010, 7:40:31 PM5/6/10
to ks...@googlegroups.com
하이버네이트 관련 내용은 아닌데, 기본 구조가 같다면 같은 table을 쓰면 되지 않을까요.
게시판 마다 다른 table을 만들 필요가 있는지를 잘 모르겠어요.

아마 비슷한 entity를 별도로 만드시려는 의도가 논리적으로 좋은(옳은?) 구조를 위해서 일 것 같은데
비슷비슷한 table 유지에 따르는 비용이 좋은 논리 구조 유지로 얻는 이익보다 큰 경우가 많을 것 같습니다.

@질문에 답변은 안되는군요. ^^;


2010/5/6 Young Gyu Park <ygp...@gmail.com>

김성국

unread,
May 7, 2010, 10:46:31 AM5/7/10
to ks...@googlegroups.com
abstract 상위 클래스를 만들어서 @Entity 대신에  @MappedSuperclass 어노테이션을 쓰고..
 
이 클래스를 상속받아서 하위 도메인 클래스를 만들면 됩니다.
 
이렇게 할 경우 상위 클래스의 모든 속성이 그대로 별도의 테이블로 구현되겠습니다.
 
다만 정말 비슷비슷한 게시판들이라면... Sewon Ann님 말씀대로 합쳐버리고 구분키를 주는게 더욱 어울려 보입니다.
 
저의 경우 위의 상속은 거의 모든 테이블에 항상 들어가는 createdBy, createdTime, modifiedBy, modifiedTime 과 같은
공통적으로 사용하는 컬럼만 정의해놓고 상속 받아서 사용하고 있습니다.
 
toString, hashCode, equals 매서드도 추상으로 선언해놓고
강제로 구현하도록 하고 있구요.... 이거 안해놓으면 꼭 몇몇 개발자들이 빼먹더라는... ㅡㅡㅋ;

One Bread

unread,
May 7, 2010, 7:12:46 PM5/7/10
to ks...@googlegroups.com
성능을 위해서 매 게시판 마다 또는 게시판 그룹 별로 테이블를 다이나믹하게 만드는 기법이라면 하이버네이트에서는 원천적으로 불가능해요. SQL을 그때 그때 조합해서 만들어야 하는데 하이버네이트는 테이블 메타 데이터와 특정 클래스를 미리 매핑해놓기 때문이죠.

테이블 자동 등록기법을 포기하시고 DB를 최적화해서 사용하시거나, 하이버네이트를 포기하시고 다이나믹한 SQL생성이 가능한 JDBC나 iBatis를 이용하셔야 할거에요.

테이블 자동 생성은 아니고 단지 비슷한 테이블을 여러 개 쓴다면 엔티티 클래스의 상속을 이용하시면 될 것이고요.

2010/5/7 Young Gyu Park <ygp...@gmail.com>

Young Gyu Park

unread,
May 9, 2010, 1:15:08 AM5/9/10
to ks...@googlegroups.com
네 그렇군요.
 
성능을 위해서 그런 생각을 했었는데, 그런 제약 사항이 있군요.
엔터티 클래스의 상속을 생각해 봐야 하겠군요.
 
답변 주신 모든 분들 감사합니다.
 
저에게는 정말 소중한 정보였습니다.
2010/5/8 One Bread <onebre...@gmail.com>

sungchul park

unread,
May 9, 2010, 7:30:32 AM5/9/10
to ks...@googlegroups.com
성능을 위해서 그런 생각을 했었는데, 그런 제약 사항이 있군요.

성능을 높이려고 그런 식으로 DB를 운영하는 일이 많은데 사실 DBMS가 고민해야 할 일을 프로그래머가 원칙을 어기면서까지 대신 처리하는 상황이라고 할 수 있죠.
사용하시는 DB가 어떤 것인지 모르겠지만 Partitioning 기능을 알아 보시면 도움이 되리라 생각합니다.

여기를 참고하세요.

http://en.wikipedia.org/wiki/Partition_%28database%29

 

Young Gyu Park

unread,
May 9, 2010, 11:35:08 PM5/9/10
to ks...@googlegroups.com
지금 디비는 postgreSQL사용중입니다.

디비 파티셔닝도 알아봐야겠군요.

혼자서 모든걸 다 하다보니 정말 몸이 열개라도 모자라겠네요.

저같은 영세 업자들의 비애죠.... .

2010/5/9 sungchul park <gyu...@gmail.com>

sungchul park

unread,
May 10, 2010, 1:35:08 AM5/10/10
to ks...@googlegroups.com


지금 디비는 postgreSQL사용중입니다.
 
좋은 DB 쓰시네요. 요즘 pgsql 사용자가 은근 많아져서 기분 좋습니다. 국내에 보급되는 속도가 너무 느리네요.
 
 
혼자서 모든걸 다 하다보니 정말 몸이 열개라도 모자라겠네요.
저같은 영세 업자들의 비애죠.... .

그래도 혼자서 알아서 하는 게 바보랑 같이 일하는 것 보다는 낫습니다. ^^
힘내세요.


Reply all
Reply to author
Forward
0 new messages