하나의 실체 류 가 여러 표 에 대응 하 는 어려움 을 보면 Hibernate 의 실체 표 와 제 가 Hibernate, ORM 디자인 이념 에 대한 인식 을 볼 수 있 습 니 다.

     요 며칠 업무 중 에 업무 에 필요 한 종 류 를 설계 해 야 하 는데 이 종 류 를 데이터베이스 에서 꺼 내 려 고 할 때 Hibernate 를 사용 하 는 것 이 쉽 지 않다 는 것 을 알 게 되 었 다.작업 코드 가 좋 지 않 으 면 직접 꺼 내 서 많 지 않 은 예 를 들 어 보 세 요.
 
     예 를 들 어 사용자 가 시스템 에 저 장 된 정 보 는 간단 한 정보 (사용자 이름, 연락처, Email, 성별) 와 일부 이미지 정보 (사진) 를 포함한다.
 
     그러나 시스템 을 디자인 할 때 제 디자인 방식 은 모두 업무 의 수요 에 따라 '사용자' 류 를 디자인 합 니 다. 사용자 이름, 연락처, 이메일, 성별 과 사진 정 보 를 포함 합 니 다. 이 럴 때 저 는 데이터 베 이 스 를 고려 하지 않 습 니 다. 이것 은 디자인 원칙 입 니 다. "
실현 이 설계 에 방해 가 되 지 않 는 다.
 
     뒤에 있 는 데이터베이스 디자인 에 서 는 사진 이 크기 때문에 저장 할 때 두 개의 표 로 디자인 됩 니 다. 사용자 요약 정보 표 와 사용자 사진 표, 두 개의 표 는 '사용자 ID' 필드 를 통 해 연 결 됩 니 다.
 
     JDBC 를 사용 하 는 것 이 간단 하 다 면 SQL 을 직접 사용 하고 공동 검색 을 통 해 사용자 의 모든 정 보 를 찾 아 대상 으로 되 돌아 가 는 것 이 간단 합 니 다. 그러나 프로젝트 초기의 디자인 개발 자 들 이 Hibernate 를 선 택 했 기 때문에 이 방향 을 따라 만 했 을 뿐 어렵 다 는 것 을 알 게 되 었 습 니 다. Hibernate 의 메커니즘 은 표 가 하나의 '실체 대상' 에 대응 하 는 것 이기 때 문 입 니 다.
 
     방법 이 없습니다. 저 는 두 개의 실체 대상 을 만 들 수 밖 에 없습니다. 업무 대상 User 에서 이렇게 바 꿀 수 있 습 니 다.
 
 

    class User{
          UserSimpleInfo sinfo;
          UserPhotoIfo   pinfo;
     }

 
 
     정말 우 스 꽝 스 럽 습 니 다. 좋 은 해결 방안 이 있 을 지도 모 릅 니 다. 제 가 찾 지 못 했 을 뿐 입 니 다. 저도 계속 찾 아 보 겠 습 니 다. 지금 으로 선 이 방면 의 좋 은 자 료 를 찾 지 못 했 습 니 다.
 
     나 는 지금 이것 이 불가사의 한 방법 이 라 고 생각한다. 대상 의 디자인 은 업무 의 분석 과 업무 논리 에서 나 와 야 한다. 디자인 과 그렇게 밀접 한 관 계 를 가지 지 않 는 다. 디자인 이 실현 되 어야 한다 고 생각 하고 실현 에 의 해 디자인 을 결정 해 서 는 안 된다. 하나의 실현 이나 하나의 틀 이 든 기능 이 강하 든 아니 든 '납치' 디자인 을 해 서 는 안 된다. '굴종' 을 설계 해 야 한다.이것 은 프레임 디자인 의 기본 원칙 이다.
 
     실제로 하나의 표 가 하나의 실체 대상 에 대응 하 는 것 은 많은 상황 에서 자 연 스 러 운 선택 이다. 그러나 반드시 필요 한 방법 은 아니다. 만약 에 이렇게 디자인 하여 실현 해 야 한 다 는 것 을 제한한다 면 그것 은 매우 황당 한 것 이다. 내 가 자주 대상 하 는 분야 와 고객, 자주 직면 하 는 장면 에서 한 대상 을 몇 개의 표 로 나 누 는 것 은 매우 가능 한 일이 다. 그래서 ORM 은 이런 장면 을 지지 해 야 한다.。
 
     다른 측면 에서 볼 때 하나의 표 가 하나의 실체 류 에 대응 하 는 것 은 고려 하지 않 은 이념 이다. 물론 ORM 은 하나의 맵 여러 개의 표를 지원 하면 복잡 도가 많이 커지 고 사용 하기 도 더욱 어렵다. 어 쩔 수 없다. 통용 되 는 것 을 하려 면 하나의 영역 과 업무 로 전환 하 는 것 보다 어 려 울 것 이다.
 
     저 는 원래 ORM 이라는 것 을 좋아 하지 않 습 니 다. 그래서 저 는 Hibernate 와 같은 ORM 프레임 워 크 를 더욱 싫어 합 니 다. 그래서 인터넷 에 있 는 자 료 를 찾 았 습 니 다. 이것 은 괜 찮 은 것 이 라 고 생각 합 니 다. 특히 간단 한 장면 이 필요 하지만 이 를 지지 하 는 일부 표현 과 이 유 는 설득력 이 없습니다.
 
     어떤 사람 이 말 했다.
Hibernate 가 나타 난 목적 은 우리 가 코드 를 쓸 수 있 도록 업무 코드 를 처리 하 는 데 더욱 집중 할 수 있 도록 하기 위해 서 입 니 다. SQL 문 구 를 어떻게 구축 하 는 지 에 신경 을 쓰 는 것 이 아 닙 니 다.
 
   
 나의 의견:
SQL 자체 가 업무 논 리 를 나타 내 는 것 입 니 다. 한 제품 은 기능 적 수요 뿐만 아니 라 효율, 저장 등 수요 도 포함 하고 있 습 니 다.
 
     어떤 사람 이 말 했다.
아직 O / R 이 없어 요. MAPPING 이전에 저희 가 팀 에서 개발 할 때 업무 논 리 를 실현 하기 전의 일 은 바로 DBA 에 게 물 어보 거나 시스템 의 데이터베이스 사전 을 찾 는 것 입 니 다. 이 논리 에 사용 되 는 필드 유형, 크기, 제약 을 모두 파악 해 야 인 코딩 작업 을 시작 할 수 있 습 니 다. 특정한 SQL 문 구 를 구축 하고 코드 에 여러 가지 논리 적 판단 을 넣 어야 하기 때 문 입 니 다.
     O / R 이 생 겼 어 요. MAPPING 이후 에 야 이러한 현상 은 기본 적 인 해탈 을 얻 을 수 있 습 니 다. 왜냐하면 우 리 는 표 안의 데 이 터 를 조작 하려 면 맵 류 에 대해 직접 조작 하면 됩 니 다. O / R MAPPING 은 필요 한 SQL 문 구 를 자동 으로 생 성 합 니 다.
 
     나의 의견:
유형, 크기, 제약, 코드 에 넣 어야 할 논리 적 판단 자체 도 업무 논리의 한 부분 입 니 다. 어떤 이념 과 도 구 를 사용 하 든 고려 하고 직면 해 야 합 니 다.
 
     어떤 사람 이 말 했다.
ORM 을 사용 하지 않 으 면 get / set 이 얼마나 귀 찮 은 지, SQL 을 쓰 는 것 이 얼마나 귀 찮 은 지, 그리고 유지 하기 가 쉽 지 않 습 니 다.
 
     나의 의견:
기 존의 ORM 을 사용 하지 않 더 라 도 대상 을 대상 으로 하 는 방식 으로 데이터베이스 의 대상 과 업무 대상 을 밀봉 하여 상부 에 사용 할 것 입 니 다. 업무 차원 에서 볼 수 있 는 것 도 매우 뚜렷 한 저장, 기능 호출 일 뿐 입 니 다. JDBC 호출 과 ResultSet 의 set 와 get 이 곳곳에 있 지 않 고 SQL 이 날 아 다 니 지 않 습 니 다. 이 는 어느 정도 에 Hibernate, MyBatis 와 차이 가 있 습 니 다.많 지 않 지만 유 니 버 설 성 을 고려 하지 않 아 도 되 기 때문에 디자인 이 쉽게 이 루어 지고 자신의 제품 수요 에 따라 디자인 되 며 맞 춤 형 으로 옷 을 재단 하여 자신의 제품 에 가장 적합 합 니 다.
    
또한 SQL 을 쓰 는 것 에 대해 서 는 SQL 을 잘 쓰 는 것 이 설계 와 실현 자의 기본 이 라 고 생각 합 니 다. 여기 서 게 으 름 을 피 워 서 는 안 된다 고 생각 합 니 다. 누 군가 말 한 것 (누 군지 잊 어 버 렸 다) "SQL 은 추 해서 이해 하기 어렵 습 니 다."이 말 은 설득력 이 없다. 만약 SQL 이 사악 하 다 면 JNI 는 어떤 것 일 까? SQL 은 매우 세련 되 고 우아 한 언어 이자 예술 이다. SQL 에는 매우 세련 되 고 깨끗 하 며 뚜렷 한 개념 이 담 겨 있 으 며 매우 안정 적 인 구조 가 담 겨 있다.
 
     나 는 효율 적 인 측면 에서 만 문 제 를 고려 하지 않 을 것 이다. 나 는 더 많은 고려 를 한다.
     
대상 은 업무 분석 에서 대상 과 데이터 베이스 시트 는 아무런 관계 가 없 으 며, 대상 은 데이터 저장 층 에서 꺼 낼 수 있어 야 하 며, 저장 층 을 통 해 저장 할 수 있어 야 한다. - 어떤 표 형식 등에 대해 서도 이러한 상부 디자인 에 영향 을 주지 않 는 다. 데이터 베이스 표 에서 실체 대상 이 발생 하 는 것 은 매우 나 쁘 고, 실체 대상 에서 표 구조 가 발생 하 는 것 도 마찬가지 로 좋 지 않다.업무 에서 볼 때 표 의 디자인 은 대상 의 디자인 과 데이터 베이스 자체 의 특징, 제품 또는 프로젝트 의 수요 (예 를 들 어 효율 수요 와 서로 다른 데이터 베이스 자체 의 서로 다른 특성) 에 따라 이 루어 진 것 이다.
     
하나의 프로젝트 와 제품 은 디자이너, 실현 자, DBA 가 공동으로 노력 해 야 하거나 다른 상황 이 많 습 니 다. 한 팀 에 데이터베이스 나 SQL 에 정통 한 사람 이 한 명 또는 몇 명 있어 야 합 니 다. 같이 해 야 합 니 다. 'SQL 을 잘 모 릅 니 다' 라 거나 'SQL 을 잘 쓰 는 것 이 너무 어렵 습 니 다' 라 고 말 해 서 는 안 됩 니 다.이 유 를 들 어 효율 과 저장 에 대한 수 요 를 외면 하거나 "OO 와 관계 데이터 베 이 스 는 천연 임피던스" 라 고 쉽게 말 할 수 있 습 니 다. 데이터 지구 층 을 잘 만 들 려 면 데이터 베이스 와 SQL 에 익숙 하거나 정통 해 야 하 는 사람 이 어야 합 니 다.
 
     또는 효율, 저장, 지속 성에 대한 요구 가 없 는 프로젝트 나 제품 을 만 드 는 것 은 별 개의 문제 입 니 다. 아니면 한 동안 의 학습 과 체험 을 통 해 저 는 현재 의 생각 을 바 꿀 것 입 니 다.