Page History
...
| Code Block | ||||||
|---|---|---|---|---|---|---|
| ||||||
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 | ||
|---|---|---|
| ||
|
| Note | ||
|---|---|---|
| ||
SQL-PART B부분이 자연스럽게 ORM으로 표현이 가능하다라고 하면 ORM의 고급부로 더 진행하려고 하였지만 잠시 멈춘상태입니다. SQL 의 CASE문 UNION, 윈도우함수를 통한 집계등 집계를 위해 선언형 인 SQL문을 ORM(JPA) 사용하여 표현하려 하였지만 , 표준적이지 않고 실제 사용하려던 쿼리방식에서 불일치가 발생하며 뭔가 어색합니다. DB를 다루는 방식인 비지니스모델을 스키마와 엔티티에 녹여내고,여러 관계를 포함 제약조건걸고 중복제거 정규화 하는과정등 OOP의 설계 과정과 불일치 합니다. ORM은 쿼리를 모르는 사람이 편리하게 사용할수 있는 툴일까? 로 시작하였지만 여기서 생각의 전환이 발생하였습니다. ORM은 DB를 더 잘 이해하고 OOP로 일치시키려는 컨셉을 가지고 있기때문에, DB와 OOP 연마를 평균이상 더 해야합니다. 그러고도 복잡한 쿼리에대한 성능문제 예를 들면 N+1의 문제를 해결해야합니다. ORM을 사용하기위해서는 개발 패러다임이 바뀌어야하고 더 높은 수준의 개발자가 있어야한다는것이 저의 생각입니다. 정리: 쿼리를 사용하지 않고, 우리가 원하는 랭킹처리를하였습니다. 항상 권장되는 방식은 아니며, SQL 영역에서는 SQL문작성을 못해서 어플리케이션에서 절차식 으로 처리하는 사고방식을 초보라고 언급하기도 합니다. 하지만 이것은 SQL방식과 유사한 식을 사용한 선언형방식이며 실제 데이터베이스 내에서 윈도우 랭크함수가 작동될 구현체를 어플리케이션에서 유사하게 구현을 하였습니다. 단일 성능에서 DBMS가 더 빠르냐? 어플리케이션이 분담하여 처리하느냐? 는 각각 다른문제이며 단순하게 DBMS에서 수행할수 있는 영역을 어플리케이션이 절차식으로 풀었다고 초보로 정의하는것은 바람직하지 않습니다.
어플리케이션에서는, 쿼리로 1차 범위 제한을 적절하게 한다고 해도 원하는 랭킹을 얻기까지 더많은 결과셋이 필요할수 있다란것이 단점입니다. SQL문 학습과 함께, 어플리케이션에서 데이터 가공을 람다식으로 하는것은 절차식 사고방식을 벗어나 SQL작성과 비슷한 선언형 사고방식을 하는것으로 람다식을 같이 연습하는것을 추천합니다. 결론은 원하는 값을 얻기위해 가장 짧고 깔끔한 SQL문을 작성하는 노력을 함과 동시에 어플리케이션에서 연산을 옮겨왔을시 아주큰 이점이 있는지? 고민을 하는것입니다. |
