테이블 정규화 vs 조회 성능

Question

안녕하세요 ! 사이드 프로젝트를 진행 중인 취준생 입니다코틀린+스프링 간단한 crud 앱인데, 현재 테이블 구조에 대해 고민이 커져서질문드리게 됐습니다. 처음에 테이블을 설계할때 조인을 최소화 하고 자주 사용되는 정보들만 인덱스를 걸어야겠다는 생각으로 메인 엔티티에 필요한 정보만 넣었는데 컬럼이 10개가 되어버렸습니다 .. ㅎㅎ 테이블은 총 7개 이구요하나의 테이블에 컬럼이 이렇게 늘어날 경우에 조인은 덜 발생되지만 , 조회 성능이 떨어지게 되고 insert 나 update 시 비용도 많이 발생하게 됩니다 또한 데이터가 쌓일 경우 디스크나 메모리 공간의 사용량도 많아지겠지요 .. 그렇다고 단일 테이블만 쓰는것도 아니고 조인을 할 상황은 반드시 발생하게 되구요 그런데 또 이 테이블을 정규화 하게 되면 자주 찾는 정보를 조회 할 때 항상 조인을 해야 되는 상황이 발생하게 됩니다 더불어 insert 작업을 할때 객체 생성을 2번 해야 해서 로직이 복잡해지고 유지보수가 어려워진다는 단점이 있습니다 대안 1 . 단일 테이블로 가져가되 컬럼을 최소화 한다 ( 데이터가 수천건 이하 일경우 )대안 2. 정규화를 하고 조인 대신 뷰를 생성하여 조회 성능을 높힌다 대안 3. 단일 테이블로 가져가되 , 자주 조회 되는 정보들만 캐시에 저장한다 (redis )두서 없는 글 읽어주셔서 감사합니다 ! 혹시 다른 대안이 있다면 댓글 남겨주세요! 여러분의 의견이 궁금합니다

amiwho · Answer

정규화를 하고 조인 대신 뷰를 생성하여 조회 성능을 높힌다?? Materialized말씀하시는건가요?

catcode · Answer

본 질문과는 상관 없는 말이긴 한데실무에서는 정규화, 성능보다 유지보수, 확장성을 더 중시합니다..

톰소여 · Answer

질문으로는 정확히 알 수가 없어요.plan이나 응답 속도 보고 이상 없으면 그냥 쓰는 것도 괜찮아요.조인이 많아도 플랜에 정상적으로 인덱스 스캔 하는 걸로 뜨면 크게 문제 없습니다.view는 안쓰는 것이 좋아 보이네요.당연히 jpa 쓰겠지만..mybatis면 sql part 로 뷰와 비슷하게 만들어서 사용하는 것이 더 나아보입니다.

엡실론 · Answer

조인을 두려워 하지 말고 정규화하세요.많은 경우 조인이 성능 문제를 일으키진 않습니다. 역정규화는 정말 조인이 문제임이 확실할때, 여러가지 상황을 보면서 할 일입니다. 상황에 따라서 단순히 조인을 피하기 위한 역정규화가 아니라, 다른 접근이 필요할 때도 있습니다.정규화된 테이블이 유지보수성도 더 좋습니다. 유지보수성은 기본적으로 남이 봤을때 코드를 쉽게 이해할 수 있는가에 달려 있습니다. 역정규화가 되면 올바른 데이터를 생성하기 위한 여러가지 규칙들이 추가 되고 여기서 읽어서 저기다 넣고 하는 식의 코드가 많아 질텐데, 훨씬 더 이해하기 힘들어집니다.

이메일 수신동의 · Answer

Balancing data integrity with retrieval speed is always a challenge. De-normalization can sometimes improve query performance, but at the cost of redundancy and potential inconsistencies. What strategies do you find most effective when deciding on the right level of normalization for a particular database design? This makes me think about the Dinosaur Game.

장독깨기 · Answer

테이블을 구조화하는데요, 컬럼 갯수, 테이블 갯수, 조인 성능 우려, 유지보수성, ...지금 고민하고 있는건 전혀 고려 대상이 아닙니다.무조건 정규화를 하셔야 합니다.www.erdspace.com ERD 편집 툴 입니다. 여기 한 번 이용해보세요. : )

Kyeongrok Kim · Answer

join때문에 느려지는 것은 테이블 설계를 잘못 했기 때문이지 join자체가 문제는 아닙니다. 속도 때문에 정규화를 못한다는 것은 지금 레벨에서는 방어기재이거나 핑계라고 볼 수 있습니다.

MungGaeDev · Answer

다분히 실무적인 면에서 데이터 수만건 이하는 최적화 고려대상이 아니라봅니다

yeori · Answer

처음에 테이블을 설계할때 조인을 최소화 하고X

개발자인데코딩을모름 · Answer

테이블 정규화시에 정규화말고 역정규화를 해보는 건 어떨까요?

RuthAmbler · Answer

I remember struggling with similar normalization dilemmas on a past project, especially with user profiles. It's a tough balancing act! For me, a hybrid approach of slight denormalization for frequently accessed core data, combined with a robust caching layer (like your Redis idea), often yielded the best results without overcomplicating things. It made me wish I had 'Crazy Cattle 3D' to blow off some steam after all that database design!

테이블 정규화 vs 조회 성능

11개의 답변

기술 목록