19 câu hỏi đã được viết

1

안녕하세요 질문 감사드립니다!
이 부분은 전략에 대한 것을 수강생 분들이 느끼셨으면해서 그렇게 구성해두었는데요! 아주 좋은 질문입니다!

해당 코드에 대한 배경은 일반적으로 상품의 옵션은 많지 않다 를 전제로 하고 있습니다
그 전제에서는 굳이 디비를 통해서 정렬이나 필터링을 하지 않아도 크게 부하의 차이가 없고(관련 인덱스가 없다는 전제) 오히려 DB의 쿼리 수행 속도가 더 올라가게 되는 이점이 있습니다.

결국 디비에서 관련 인덱스가 없다면 DB의 컴퓨팅 리소스를 쓰게 되는 것 이니까요
굳이 이 배경을 더 넓게 생각해보면 일반적으로 디비는 한정 자원입니다 (스케일 업과, 아웃이 다 가능하지만 읽기 지연, 멀티 마스터 등으로 가려고하면 할 수록 복잡해지죠)

반대로 어플리케이션을 확장하기가 쉽습니다, 그래서 우리 서비스의 상황을 적절히 판단해서 적절한 엔지니어링을 해야한다고 생각합니다!

+ 그치만 사실 일반적으로 상품의 옵션은 많지 않다 전제라면 DB로 인덱스 없이 조회 해도 상관 없습니다ㅎㅎㅎㅎ;;; 수강생 분들이 고민 한번 해보셨으면해서 구현을 적용 해두었습니다

다만 상황이 달라져서 이미 인덱스가 있고 옵션을 날마다 생성하고 삭제하는 서비스라면 DB에게 부하를 더 주는게 맞는 전략이 될 것 입니다!

모쪼록 답이 되었길 바랍니다! 감사합니다!

0

안녕하세요, 인프런 AI 인턴입니다. hahahl님.

질문해주신 부분은 데이터베이스 레벨에서의 연산과 애플리케이션 레벨에서의 연산 중 어느 것을 선택할지에 대한 고민으로 보입니다. 일반적으로, 데이터베이스 레벨에서 필터링과 정렬을 수행하면 데이터 전송량을 줄일 수 있고, 이는 성능적으로 유리할 수 있습니다. 그러나, 애플리케이션 레벨에서 코틀린의 filter와 sort를 사용하는 것도 특정 상황에서 적합할 수 있습니다.

몇 가지 이유를 고려해볼 수 있습니다:

1. 비즈니스 로직의 복잡성: 데이터베이스 쿼리로 처리하기에는 비즈니스 로직이 복잡할 경우, 애플리케이션 레벨에서 관리하는 것이 더 쉽고 직관적일 수 있습니다.

2. 데이터 처리량이 많지 않을 때: 가져오는 데이터의 양이 적고, 메모리에 로드한 후 처리해도 성능에 큰 영향을 주지 않는 경우에 애플리케이션 레벨에서의 처리가 효율적일 수 있습니다.

3. 유지보수 및 가독성: 코드를 읽고 유지보수하기 편리하게 하려는 경우, 또한 코드의 일관성을 유지하려는 목적에서 애플리케이션 레벨에서 처리하는 경우도 있습니다.

4. 최신성: 데이터베이스 쿼리를 자주 변경하지 않고, 애플리케이션 로직에서 데이터 처리를 하고 변화가 필요할 때 신속히 대응할 수 있도록 설계된 경우입니다.

만약 데이터의 양이 매우 큰 경우에는 DB 레벨의 쿼리를 통해 성능 최적화를 추구하는 것이 일반적인 방법입니다. 하지만 데이터의 특성, 트래픽 유형, 성능 요구 사항에 따라서 최적의 방법이 달라질 수 있습니다. 때로는 임시적인 선택일 수도 있으며, 향후 확장성을 고려한 유연한 구조로 시작했을 수 있습니다.

관련하여 아래 자료도 참고하시면 좋을 것 같습니다:
- 사용자가 상품을 선택하고 쿠폰을 고를 때 가장 혜택이 큰 쿠폰을 고르는 상황: 필터링과 최적화 로직에 대한 고찰.

저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.