쿼리는 아무리 복잡해 봤자 SW 자료구조에 비하면 좆도아니고
복잡한 쿼리 자체가 리트코드 복잡한 쿼리문제, 백준에 골드 수준에도 못비비는 걍 침팬치 노가다 수준인데
쌩쿼리 박는 거 좋아하는 애들있음 물론 서버 구조가 데이터 중심이면 쿼리쳐박는게 맞음
이런 어플리케이션을 주로 다뤘으면 orm이 좆같은게 맞음 근데 요새 JPA 같은 ORM 배워 쳐오는 애들 중에
db 쿼리도 못쓰고 ORM이 뭔지도 모르는 새끼들이 너무 많음
ORM 쓰는 이유는 하나임 뭐 쿼리를 자동 매핑해주니, DDL이 자동생성되니 코드수준에서 데이터베이스 관리가 되니
이딴 게 중요한게 아니라 딱하나임
DB 엔티티 모델을 비지니스 엔티티 모델로 어플리케이션 모델 중심으로 코드를 짤 수 있다는 거임
그딴 N+1 문제 해결하는게 중요한게 아님
엔티티 모델과 비지니스 모델의 간극을 어떻게 잘 모델링 할 수 있는 능력이 훨씬 더 중요함
오브젝트 모델로 다룬 후에 성능 튜닝에 들어가는 거지
근데 복잡하면 복잡해질 수록 ORM은 어쩔 수 없이 나눠지고
서로 참조해지는 게 많아지면 도메인 분리가 들어감
쿼리 전용 모델이 생기고 EDA 이벤트 패턴들이 점점 어쩔 수 없이 쓰여지는 거임
한계가 있으닌깐
이 orm 분리하는게 msa 모듈 분리 도메인 분리랑 완전히 똑같기 때문에
orm도 msa에 기여를 꽤 한 거임 이거 모르는 새끼들도 많음
뽑은건 기업인데 ??ㅋㅋㅋ 개씹셍징기업 수준 ㅋㅋ뽑아놓고 욕하기 ㅋㅋ
기업이야기 1도없는데
쿼리를 자동생성해주는게 가장 큰 기능임 그런데 구현해야할 쿼리가 복잡해질수록 orm은 배보다 배꼽이 더 커진 기형이 되어버림
orm 진영은 10년 넘게 복잡한 쿼리 안쓰려고 하고 있는데 복잡한 쿼리를 orm에 맞추려고 하는게 문제라는 거죠
orm에 모든걸 의존할 필요가 없음 orm은 그냥 단순한 쿼리용임 orm을 위해 앱 기능이나 성능을 포기하는것 역시 배꼽을 위해 배를 포기하는 선택
아이거 나보다 경력 많아 서 뭐라할 수도 없고
동의는 하는데 orm이 단순 쿼리용도로라는 건 orm을 쿼리로써밖에 생각 안햇다는건데
그 이상 사용해본적도 없는거고
참고로 난 orm 예찬론자가 아닙니다
디비모르는 개발자 중에 orm 이 좋다좋다하는데 왜 좋은지도 모르고 쓰는애들한테 한 마디한거고 내 경험상 매퍼 쓰다가 orm 쓰는 애들이 기존 orm만 배우고 쓰는 애들모다 모델 이해도가 높아서 딱히 매퍼쓰는 애들 비하하는 것도 아니구요
ㅇㅋ 본인도 본인의 생각을 이야기한것 뿐이다 아무튼 본인은 orm을 사용하더라도 절대 orm만으로 모든걸 하지는 않음 ㅇㅅㅇ
맞습니다. orm 역시 개발자 레벨에서 영속성을 구현해야하기 때문에 RDB를 사용하면 의존될 수 밖에 없으며 RDB와 ORM의 간극을 매꾸기 위해 추가적인 구현이나 기능이 필요합니다. 그렇기 때문에 추가 라이브러리라 쿼리 빌더들이 존재하는 거구요 ORM의 기본 철학은 데이터베이스, RDB가 아닙니다 어플리케이션이죠
다만 그렇다고 sql 매퍼는 어플리케이션을 몸통을 만들 수 없냐? 그것도 아니죠 객체 모델링은 영속성과 관련이 없습니다. jpa로 구현하던 마이바티스로 구현하던 상관 없습니다. 다만 jpa가 좀 더 어플리케이션단에서 객체 사용하기 더 쉽고 더 잘 유도할 수 있습니다. 하지만 어짜피 orm도 영속성 구현을 해야하는데 이게 sql 매퍼를 쓰는 것보다 러닝커브 성능 뭐 다양한 부분에서 배를 포기하는 선택이 될 수 있는건 동의합니다
테이블을 객체로 다룰수있는게 가장 큰 장점아니냐
그 말하는건데
내가 이해한게 맞나 다시확인해봤음
본질을 봐야댐 데이터베이스 엔티티를 자바 진영에 매핑시켜서 다룰때의 장점이 뭐가있는지를 생각해보면됨 그 장점이 결국 ORM 탄생의 본질 철학임 - dc App
db 엔티티와 어플리케이션 비지니스의 객체와의 간극이 없으면 왜쓰는지 모를 수 있지 않노? 이러한 간극이 생기기때문에 어플리케이션단에서 작업하는 사람은 편하다노
간극이 없을 수가 없는데 이건 모델링 한번도 안해봤단 소리
쉬운구조면 간극이 없을수도 있지 않겠노?
당장 테이블 2개 1:N 만 있어도 간극이 없을 수가 없어요
ㄹㅇ ORM이라는 명칭부터가 객체와 RDB를 맵핑한다는 건데 그걸 이해 못함