2-3달간 코딩을 손에서 놓고 있었더니, 다시 손을 대려니까 정신이 멍해지더군요. 의욕은 나이를 먹을 수록 자꾸만 줄고 있고... 이래서 사람들이 나이 먹어서 코딩하는 역량이 줄어드나 봅니다. (라고 해도 요즘은 점차 개발자 연령 증가 추세인데 혼자서 농땡이 피는 듯 -_-)
어쨌거나 자바로 간단한 O/R Mapper 를 만들어보고 있는 중입니다. 써먹을 데도 몇 군데 있고 해서, 개인적으로 개발중인 패키지에 묶어서 코딩하고 있습니다.
진행중, Entity 에 대한 클래스 외적인 기술방법이 필수적으로 요구된다는 것을 깨달았습니다.
처음에는 가급적 간단하게 개발하기 위해, 별도의 외부 기술 방법 없이 클래스 내부에서 직접 Entity 를 가지고 데이터베이스에 저장할 구조를 모두 유추하는 방법을 생각했습니다. 다음과 같은 방식이죠.
1) 매퍼에 새로운 클래스 등록을 요청하면, Reflection 을 통해 클래스 정보를 읽어 이 클래스와 매핑되는 테이블을 생성.
2) 개체가 들어오면 Reflection 을 통해 클래스를 추정하고 이에 해당하는 테이블로부터 Entity 정보를 읽어와 인스턴스를 생성
여기서 결정적인 문제가 발생하게 됩니다. 클래스만으로는 키 집합을 기술할 방법이 없다는 점이었죠. 키 집합을 기술하지 못하는 것은 다음과 같은 문제를 일으키게 됩니다.
1) 각 원소간의 고유성 표현 불가.
2) 검색속도의 저하
가장 치명적인 문제는 1) 입니다. 예를 들어 어떤 데이터를 가져와 특정 정보를 수정하고 이를 다시 업데이트해야 한다고 했을 때, 가져온 데이터와 수정된 데이터가 원래는 같은 정보였으며 값을 수정하기 위해 변경되었다는 것을 지시해 줄 무언가가 필요하게 됩니다.
Primary Key를 사용하는 중대한 이유 중 하나가 바로 이것입니다. 해당하는 Entity 의 고유성을 표현할 부분이 어디인지를 명시하는 역할을 수행하는 것이죠.
이것이 존재하지 않을 경우, 특정한 개체를 '수정해야' 한다면 방법은 하나뿐입니다. 이전의 데이터와 완전히 동일한 데이터 중 하나를 지우고 새로운 데이터를 삽입하는 것이죠. 하지만 실제로는 동일 개체가 여럿 있었을 경우 어떻게 해야 할 지 모호하다는 문제 및, 삭제 한 번 할 때마다 무시무시한 검색을 수행해야 한다는 치명적인 문제가 발생합니다.
2) 번의 경우는 뻔하므로 별도로 설명하지 않겠습니다. 인덱싱 된 데이터와 그렇지 않은 데이터간의 검색속도 차이는 엄청나다는 말로도 기술하기 힘들 정도니까요.
물론 외부 기술 방법이 없다고 하더라도 몇 가지 해법은 존재합니다.
1) 키 집합을 별도의 클래스화 한 후 Entity 를 기술하는 클래스 하위 참조에 연결. 혹은 키 집합과 데이터 집합을 나누고 이 두 집합을 Composite 하는 추가 클래스 생성
2) 키를 1개만 사용할 수 있게 하고, 키 필드의 명칭을 고정
하지만 두 해법 모두, 기존 Entity 에 거의 손대지 않고 사용할 방법은 없습니다.
2) 의 경우는 명칭을 고정해야 하므로 기 작성 코드를 수정하지 않는 한 아예 방법이 없고,
1) 의 방법은 래핑 클래스와 키 클래스를 추가로 작성하는 방식으로 그나마 기 작성 코드에 대한 수정을 최소화 할 수 있으나, 최종적으로 Entity 가 저장될 때 별도의 매핑작업을 통해 (그게 Reflection 을 활용한 것이든 단순히 If 를 활용한 구문이든) 연결시키는 작업을 수행해야 하기 때문에 퍼포먼스 저하 및 코드의 복잡성을 야기하게 됩니다.
따라서 내린 결론은 재사용성이나 성능을 포기하더라도 단순성을 추구해야 하는 것이 아니라면, 외부 기술 방식을 사용하는 것이 유용하다라는 것이었습니다.
다만, 그것을 어떻게 할 지는 아직 결정내리지 못했습니다.
어쨌거나 자바로 간단한 O/R Mapper 를 만들어보고 있는 중입니다. 써먹을 데도 몇 군데 있고 해서, 개인적으로 개발중인 패키지에 묶어서 코딩하고 있습니다.
진행중, Entity 에 대한 클래스 외적인 기술방법이 필수적으로 요구된다는 것을 깨달았습니다.
처음에는 가급적 간단하게 개발하기 위해, 별도의 외부 기술 방법 없이 클래스 내부에서 직접 Entity 를 가지고 데이터베이스에 저장할 구조를 모두 유추하는 방법을 생각했습니다. 다음과 같은 방식이죠.
1) 매퍼에 새로운 클래스 등록을 요청하면, Reflection 을 통해 클래스 정보를 읽어 이 클래스와 매핑되는 테이블을 생성.
2) 개체가 들어오면 Reflection 을 통해 클래스를 추정하고 이에 해당하는 테이블로부터 Entity 정보를 읽어와 인스턴스를 생성
여기서 결정적인 문제가 발생하게 됩니다. 클래스만으로는 키 집합을 기술할 방법이 없다는 점이었죠. 키 집합을 기술하지 못하는 것은 다음과 같은 문제를 일으키게 됩니다.
1) 각 원소간의 고유성 표현 불가.
2) 검색속도의 저하
가장 치명적인 문제는 1) 입니다. 예를 들어 어떤 데이터를 가져와 특정 정보를 수정하고 이를 다시 업데이트해야 한다고 했을 때, 가져온 데이터와 수정된 데이터가 원래는 같은 정보였으며 값을 수정하기 위해 변경되었다는 것을 지시해 줄 무언가가 필요하게 됩니다.
Primary Key를 사용하는 중대한 이유 중 하나가 바로 이것입니다. 해당하는 Entity 의 고유성을 표현할 부분이 어디인지를 명시하는 역할을 수행하는 것이죠.
이것이 존재하지 않을 경우, 특정한 개체를 '수정해야' 한다면 방법은 하나뿐입니다. 이전의 데이터와 완전히 동일한 데이터 중 하나를 지우고 새로운 데이터를 삽입하는 것이죠. 하지만 실제로는 동일 개체가 여럿 있었을 경우 어떻게 해야 할 지 모호하다는 문제 및, 삭제 한 번 할 때마다 무시무시한 검색을 수행해야 한다는 치명적인 문제가 발생합니다.
2) 번의 경우는 뻔하므로 별도로 설명하지 않겠습니다. 인덱싱 된 데이터와 그렇지 않은 데이터간의 검색속도 차이는 엄청나다는 말로도 기술하기 힘들 정도니까요.
물론 외부 기술 방법이 없다고 하더라도 몇 가지 해법은 존재합니다.
1) 키 집합을 별도의 클래스화 한 후 Entity 를 기술하는 클래스 하위 참조에 연결. 혹은 키 집합과 데이터 집합을 나누고 이 두 집합을 Composite 하는 추가 클래스 생성
2) 키를 1개만 사용할 수 있게 하고, 키 필드의 명칭을 고정
하지만 두 해법 모두, 기존 Entity 에 거의 손대지 않고 사용할 방법은 없습니다.
2) 의 경우는 명칭을 고정해야 하므로 기 작성 코드를 수정하지 않는 한 아예 방법이 없고,
1) 의 방법은 래핑 클래스와 키 클래스를 추가로 작성하는 방식으로 그나마 기 작성 코드에 대한 수정을 최소화 할 수 있으나, 최종적으로 Entity 가 저장될 때 별도의 매핑작업을 통해 (그게 Reflection 을 활용한 것이든 단순히 If 를 활용한 구문이든) 연결시키는 작업을 수행해야 하기 때문에 퍼포먼스 저하 및 코드의 복잡성을 야기하게 됩니다.
따라서 내린 결론은 재사용성이나 성능을 포기하더라도 단순성을 추구해야 하는 것이 아니라면, 외부 기술 방식을 사용하는 것이 유용하다라는 것이었습니다.
다만, 그것을 어떻게 할 지는 아직 결정내리지 못했습니다.
반응형