Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Code Block
languagejava
themeEmacs
titleRank수행하기
	public void RankTest() {		
	     int[] score = {Integer.MIN_VALUE};
	     int[] no = {0};
	     int[] rank = {0};	
	     List<AddressAgeRank> ageRankList =  
				addressRepo.findByAgeBetween(10, 90).stream()
				.sorted((a,b) -> b.getAge() - a.getAge() )
				.map(p -> {
		             ++no[0];
		             if (score[0] != p.getAge()) rank[0] = no[0];
		             return new AddressAgeRank(p.getName(),score[0] = p.getAge(),  rank[0] );					
				})
				.collect(Collectors.toList());
	     
	     ageRankList.forEach(item ->{
	    	 System.out.println(item.toString());	    	 
	     });	    
	}
Expand
title결과



Note
title결론

ORM은 쿼리를 모르는 사람이 편리하게 사용할수 있는 툴일까? 로 시작하였지만

SQL-PART2 를 변환하면서 문제가 발생하였습니다.

ORM은 DB를 이해하고 OOP로 변환하고 일치시키려는 컨셉을 가지고 있기때문에

DB와 OOP 연마를 함께해야하며 평균이상 더 해야합니다.


그러고도 복잡한 쿼리에대한 성능문제 예를 들면 N+1의 문제를 해결해야합니다.

ORM N+1 문제를 검색하면, 엄청난 량의 각기 다른문제를 검색할수 있으며

이것을 해결하는 표준적인 방법이 없으며  ORM을 사용하는 각각의 프레임워크마다 해결방식이 다릅니다.


ORM을 사용하기위해서는 개발 패러다임이 바뀌어야하고 다음과같이 더 고난이도의 해결해야할 과제가 있습니다.

  • ORM은 전통적인 CRUD방식보다 더 높은 개발수준을 요구하는 CQRS에서 적합하다.
  • 데이터 모델을 OOP로 완벽하게 표현하는것은 불가능하다. ( DB의 관계를 OOP의 상속으로 모두 해결할수 없습니다. )
  • 데이터 마이그레이션은 항상 일어나는일이며, 이에대한 해결방식을 ORM 솔류션이 제공해야한다.
  • DB 성능의 책임이 어플리케이션쪽에 어느정도 있으며, 결국 분산 처리라는 과제를 어플리케이션도 함께해야한다.

SQL-PART B부분이 자연스럽게 ORM으로 표현이 가능하다라고 하면 ORM의 고급부로 더 진행하려고 하였지만 잠시 멈춘상태입니다.

SQL 의 CASE문 UNION, 윈도우함수를 통한 집계등 집계를 위해 선언형 인 SQL문을

ORM(JPA) 사용하여 표현하려 하였지만 , 표준적이지 않고 실제 사용하려던 쿼리방식에서 불일치가 발생하며 뭔가 어색합니다.

DB를 다루는 방식인 비지니스모델을 스키마와 엔티티에 녹여내고,여러 관계를 포함 제약조건걸고 중복제거 정규화 하는과정등

OOP의 설계 과정과 불일치 합니다. 

ORM은 쿼리를 모르는 사람이 편리하게 사용할수 있는 툴일까? 로 시작하였지만 여기서 생각의 전환이 발생하였습니다.

ORM은 DB를 더 잘 이해하고 OOP로 일치시키려는 컨셉을 가지고 있기때문에,  DB와 OOP 연마를 평균이상 더 해야합니다.

그러고도 복잡한 쿼리에대한 성능문제 예를 들면 N+1의 문제를 해결해야합니다.

ORM을 사용하기위해서는 개발 패러다임이 바뀌어야하고 더 높은 수준의 개발자가 있어야한다는것이 저의 생각입니다.

정리: