[Section1 ~ 3] 내부 조인, 외부 조인, 기타 조인

[gusdn7142]

아래 형식으로 공유할 내용을 남겨주세요~!

• 새롭게 알게 된 점
• 어려웠거나 궁금했던 점
• 업무와 관련된 내용
• 기타 (자유 내용)

[gonasooc]

새롭게 알게 된 점

• 논리적 실행 순서: FROM/JOIN (테이블 결합) → WHERE (조건 필터링) → SELECT (컬럼 선택) / 논리적 실행 순서와 달리 물리적 실행 순서가 다를 수 있다는 점, 쿼리 최적화기에 따라 달라질 수 있다는 점은 아예 생각을 못했던 내용이라 흥미로웠습니다.

어려웠거나 궁금했던 점

• 실무에서 테이블을 쪼갤 것이냐, 칼럼을 추가할 것인가 고민이 될 때 어떤 기준으로 작업을 하게 되는지(정규화/비정규화) 궁금한데, 테이블을 많이 쪼갤 경우 외래키에 대한 고민과 더불어 SELECT 할 때 상당히 여러 번의 JOIN을 해야 하기도 할 것 같다는 느낌적인 느낌이 있어서 더더욱 궁금합니다.
• 실무에서 쿼리 최적화는 어느 시점에, 어떤 판단하에 진행하게 되는지 궁금합니다.
• 이번 강의가 설계편은 아니지만, 실제로 프로젝트 착수 시 실무에서 ERD를 먼저 그려보고 테이블 설계를 하는지 궁금합니다. 실제로 기획서나 요구사항만 가지고 머릿속으로 그려질까 하는 의문이 들었습니다.
• 쿼리를 간결하게 적고 싶거나 혹은 강의에서도 alias 설정을 위한 AS나 JOIN에서 INNER나 OUTER를 생략하는 경우가 있는데, 긴 쿼리의 경우 가독성 측면에서 명시적으로 작성하는 케이스도 있는 것으로 들었습니다. 실무에서 주로 어떻게 작업하고 있는지 궁금합니다.

업무와 관련된 내용

• 업무의 실무적인 관점에서 보자면, 프론트도 본질적으로 초기 설계 단계에서 사람이 이해하기 쉬운 관점으로 접근하는 경우가 많은데, DB도 비슷한 관점에서 접근하는 게 흥미로웠습니다. 예컨대 내부 조인은 어떤 순서로 작성해도 무방하지만, 쿼리를 읽는 사람의 입장에서 어떤 데이터가 중심이 되는가에 따라 순서를 정한다거나, 외부 조인도 LEFT JOIN을 하게 되는 이유 같은 것들이 있겠는데, 결국 사람이 프로그래밍하기 쉽게 고수준의 언어가 나온 것처럼 쿼리 또한 그런 관점에서 접근하는구나 싶은 생각이 들었습니다.

기타 (자유 내용)

• [MySQL] 쿼리 최적화 1. 실행 계획 - https://velog.io/@sihyung92/query-tunning-1-execution-plan

[mixxeo]

작은 작업의 경우에는 바로 코드작업을 시작하기도 하지만, 큰 기능이 들어가는 경우 ERD를 그려보고 팀원들간 리뷰를 하고 진행합니다! 요구사항을 보면서 머릿속으로 어떤 테이블들이 필요할지 대략적으로는 그려지는 것 같고, 코드 작업을 하면서 관계나 테이블 구조를 수정하기도 합니다

[sylee6529]

쿼리 최적화는 수시로 모니터링 툴에서 Slow Query가 있는지 보고나서..자주 쓰이는지 심각성이 큰지 판단한 후 후딱 고치는 편입니다

[mixxeo]

요즘은 서버 성능도 좋고.. 그래서 서비스가 정말 고도화되고 중요한 쿼리가 아니라면 항상 최적화를 고려하고 작성하지는 않는 것 같습니다..ㅎㅎㅎ

[chordpli]

1. 최초로 설계할 때는 데이터 중복이 들어가지 않도록 최대한 정규화를 고려해서 설계를 진행합니다. 데이터 수정에 있어서 정규화가 되어있지 않으면 감당할 수 없는 상황이 발생하기도 해서요. 다만, 쿼리가 복잡해질 경우에 역정규화를 하는 경우도 있다고 들었습니다. (아직 경험해보진 못해서 더 말씀 드릴 수 있는 부분은 없네요 ㅠㅠ)

2. 슬로우 쿼리가 발생했을 때, 또는 DB 사용률이 불안할 때 확인하고 최적화를 진행했습니다.

3. 제 경험에서는 복잡한 테이블 설계의 경우에는 직접 그려보고 설계하기도 하지만, 간단한 비즈니스의 경우에는 DML을 작성하면서 구상하는 경우가 대부분입니다.

4. ORM의 경우 DTO와 매칭을 위해서 as를 별도로 사용하는 것 같아요. (필드명과 매칭을 위해)

[ZetBe]

새롭게 알게된 내용

• JOIN의 방향에 따라 출력되는 값이 다르구나
• 논리적으로 따져서 테이블을 합쳐야겠다
• MYSQL 식으로 값을 도출하기 위한 순서가 있구나(예를 들어, HAVING과 WHERE의 차이점)

어려웠거나 궁금했던 점

• 애초에 테이블을 만들 때 부터 자식 테이블과 부모 테이블을 정하는데, 이에 대한 기준이 있는가?

업무와 관련된 내용

이 부분은 없어서.. 저는 기타에 프로그래머스 sql문제를 넣을게요

기타

풀었던 문제들
프로그래머스 SQL 고득점 키트 JOIN파트 중 일부(난이도가 너무 높으면 서브쿼리를 요구해서 그나마 쉬운 것들만)

• https://school.programmers.co.kr/learn/courses/30/lessons/133027
• https://school.programmers.co.kr/learn/courses/30/lessons/59042
• https://school.programmers.co.kr/learn/courses/30/lessons/131533

[chordpli]

독립적으로 존재할 수 있는 테이블인가를 고려해요
독립적으로 존재할 수 있으면 부모 테이블, 누군가에 종속되어야 존재할 수 있다면 자식 테이블로 둡니다.

대부분 1:N의 관계에서 1이 되는 도메인이 부모 테이블이 되는 것 같습니다.

[mixxeo]

저도 준호님이랑 비슷하게 결정하는 것 같아요! 영한쌤이 말씀하신 것처럼 테이블을 나누는 것도 결국 원칙이 있다기보다 비즈니스 로직에 의해 논리적으로 결정하는 것이다보니 요구사항에 따라 많이 달라지는 것 같습니다.

[gusdn7142]

⬛ 새롭게 알게 된 점

조인은 실무에서 빈번하게 사용하여, 기본적인 개념들은 숙지하고 있었으나, 이번 스터디를 통해 반복 학습하는 시간을 가질수 있었습니다.

⬛ 어려웠거나 궁금했던 점 (복습)

1. 정규화와 조인을 분리해서 생각하는 경향이 있었는데, 떼려야 뗄 수 없는 관계라는 것을 깨달았습니다.
   • 정규화를 많이 하면 → 테이블이 많이 나뉨 → 🔴 조인의 필요성이 커짐
   • 정규화를 적게 하면 → 테이블은 단순해짐 → 🔵 조인은 줄지만, 🟠중복/데이터 이상 현상이 늘어남

---

---

2. 정규화 단계
   • 1NF (제1정규형)
     • 모든 속성이 원자 값(Atomic Value, 쪼갤 수 없는 하나의 값) 으로만 구성되어야 함
     • 예: 주문메뉴 = "아메리카노, 바닐라라떼" → 각 행에 하나씩 저장해야 함 ✅
   • 2NF (제2정규형)
     • 기본키가 아닌 모든 속성은 기본키에 완전 함수 종속 되어야 함
     • 즉, 부분 함수 종속이 없어야 함
     • 기본키가 아닌 컬럼들은 기본키의 일부가 아닌 전체에 의해서만 값이 결정되어야 한다
     • 예: 고객이름과 고객이메일은 고객ID만으로 이미 결정되므로 부분 종속 → 고객 정보는 customers 테이블로 분리 가능 ✅
       , 메뉴이름과 메뉴가격도 메뉴ID만으로 알수 있기 때문에 부분 종속 → 메뉴 정보도 menus 테이블로 분리 가능 ✅
   • 3NF (제3정규형)
     • 기본키가 아닌 모든 속성은 기본키에만 직접 종속되어야 함
     • 다른 기본키가 아닌 속성에 종속되면 안 됨 (이행적 함수 종속 제거)
     • 예: A → B 와 B → C가 성립시  A → C가 성립되어 이행적 종속 제거 (https://mangkyu.tistory.com/110)
   • 일반적으로 3NF 까지 완료하면 아래의 비정규화시의 문제점들을 해결할 수 있음

---

3. 정규화의 장점
   • 데이터 중복 최소화
     • 이샘플 고객이 여러 번 주문하더라도 고객 정보는 customers 테이블에 단 한 번만 저장됨
     • 코코아 메뉴 정보도 menu 테이블에 한 번만 존재
   • 갱신 이상 방지
     • 고객 이메일 변경 시, customers 테이블에서 한 줄만 수정 → 모든 주문에 자동 반영
   • 삽입 이상 방지
     • 주문과 무관하게 신메뉴만 따로 등록 가능
     • 예: '체리 에이드'를 주문 없이도 menu 테이블에 추가
   • 삭제 이상 방지
     • 주문 취소 시에도 고객 정보는 customers 테이블에 보존
     • 고객 히스토리 관리 가능

---

4. 조인의 필요성과 주의할 점
   • 정규화된 테이블은 각각 고객, 메뉴, 주문의 역할만 담당
   • 실제 비즈니스 요구사항(예: "이샘플 고객이 주문한 메뉴 이름과 가격 조회")을 충족하려면 JOIN이 필수
   • ⚠️ 주의할 점
     • 조인 비용 →🔴 테이블 수가 많아질수록 성능 저하 가능
     • 인덱스 설계 → 🔵 orders.customer_id, orders.menu_id 등에 인덱스를 두어 효율적인 조인 보장
     • 과도한 정규화 → 🔴 지나치게 잘게 쪼개면 조인 복잡도 증가 및 성능 저하

SELECT
    c.customer_name,
    m.menu_name,
    m.price,
    o.quantity,
    (m.price * o.quantity) AS total_price
FROM orders o  -- 자식 테이블
JOIN customers c ON o.customer_id = c.customer_id -- 부모 테이블
JOIN menu m ON o.menu_id = m.menu_id -- 부모테이블
WHERE c.customer_name = '이샘플';

---

⬛ 업무와 관련된 내용

1. 1:N 조인 시 주의할 점 (부모 → 자식 조인 | 1→N 조인)
   • 정규화된 테이블에서 부모(PK) ↔ 자식(FK) 관계를 조인할 때,
   • 부모 기준으로 조인을 수행하면 하나의 PK가 여러 자식 행 FK와 매칭되면서 결과 행이 증가할 수 있습니다.

---

⚠️ 1:N 조인 발생 쿼리 (부모 기준 조인)

SELECT m.menu_id, 
            m.menu_name, 
            m.price,
            o.order_id, 
            o.quantity
FROM menu m
JOIN orders o ON m.menu_id = o.menu_id;

---

📊 쿼리 결과 (부모 → 자식 조인)

---

[sylee6529]

새롭게 알게 된 점

조인의 특성에서 - “부모/자식 테이블 조인 간 행의 갯수를 고려하지 않고 SUM, AVG, COUNT와 같은 집계함수를 사용하면 중복된 계산 값이 나올 수도 있고 DB 성능에 큰 피해를 끼칠 수 있다.” 라고 강의에서 나왔는데,
최근 회사에서 실제 프로덕션 데이터 분석하거나 이슈 디버깅할 때, raw SQL을 자주 쓰는데
그럴 때 마다 요구사항만을 적고 GPT에게 ‘해줘’라고 하고 붙여넣곤 했던 게 생각이 났습니다.
먼저 생각하는 습관을 들이는 것이 중요하다는 말을 보고 반성하게 되었습니다.

어려웠거나 궁금했던 점

크로스조인 - 예전에 개념으로는 들어봤던 것 같은데 실제로 써볼 생각은 안해 봤습니다.
Join 조건을 빼먹어서 어쩌다가 실수로(?) 하는 것 외에는 의도적으로 해보지는 않았습니다.

그래서 진짜 사용하는 예시가 뭐가 있을까 해서 조금 예제들만 찾아보니,
강의에서 처럼 색상x사이즈 조합을 만들던가,
캘린더 앱에서 필요한 모든지점x 모든날짜 조합으로 데이터를 채워넣는다던가,
테스트데이터 뻥튀기한다던가
이런 특수 케이스에서는 필요할 수도 있겠구나 느꼈습니다.

ORM에서도 지원을 하나? 했는데, 대부분 그대로 or 준하는 기능을 제공하긴하나 Django ORM에서는 지원을 하지 않아 쓰려면 raw sql문을 써야한다고 한다고 합니다. 이정도면 흔히 쓰이는 유즈케이스가 없어서 이런 결정을 하지 않았을지.. 생각을 했습니다.

업무와 관련된 내용

없음

기타 (자유 내용)

위에서 언급한 cross join을 장고에서 쓸 수 없냐는 물음과 답변이 포함된 참고 사이트:
https://forum.djangoproject.com/t/cross-join-in-django-orm/31567

[mixxeo]

저도 raw query짤 때는... llm을 거의 전적으로 애용합니다.. ㅋㅋㅋㅋ

[gonasooc]

raw query 기가 막히게 짜줄 거 같긴 하네요 ㅋㅋ 정규식이나 쉘 스크립트도 너무 깔끔하게 짜줘서

[chordpli]

Query는 LLM이 기가막히게 짜주긴 합니다.. ㅎㅎ

[chordpli]

복잡한 Raw Query를 짜고 있을 시간을 회사에서 주지 않아요.. ㅠㅠ

[chordpli]

새롭게 알게 된 점

• 조인 작동 순서
  데이터베이스는 FROM/JOIN, WHERE, SELECT 순으로 작동하지만, 내부의 쿼리 최적화기를 통해 실행 순서가 달라질 수 있다.
  예를 들어 WHERE 문을 사용하여 먼저 필터링한 후, 진행하면 조인 대상이 줄어들어 성능이 더 최적화될 수 있다.

위 이미지를 참고하면 tenk1, tenk2를 Join하고 WHERE이 진행되어야 하지만, 실행계획을 보았을 때에 WHERE 부터 시작되는 것을 볼 수 있습니다.

Postgrdsql 문서

어려웠거나 궁금했던 점

• CROSS JOIN 을 실무에서 어떻게 사용하는지가 궁금했는데, 강의 예시 이외에도 실무에서 사용하는 경우가 있는지 궁금합니다.

업무와 관련된 내용

조인 작동 순서와 연관이 조금은 있는 듯 싶어서 작성합니다.
인덱스 손익 분기점이라는 것이 존재합니다. 특정 레코드 수를 넘어서면 인덱스 스캔 방식보다 테이블 전체 스캔(Full Scan)이 더 효율적이게 되는 지점을 의미한다고 해요. 테이블 데이터 크기의 5~20% 수준이라고 이야기하지만, 천만건의 데이터를 넘어서면 더 낮아진다고 합니다.

인계받은 쿼리에서 slow query가 발생하는 경우가 있었고, 위와 같은 사례였습니다. 실행 계획을 살펴보았을때, 조인이 되기 전에 이미 약 1,200만건의 데이터가 존재했기 때문에 Full Scan을 진행하고 있었고, 위를 해결하기 위해 기존 기획자분과 상의하여 WHERE 조건을 추가하여 인덱스를 탈 수 있을정도로 데이터를 더 작게 쪼개는 작업을 선행했었습니다.

[gusdn7142]

CROSS JOIN 사용해보지는 못했습니다. Full Outer Join은 Union으로 만들어서 써보곤 했습니다.

[mixxeo]

새롭게 알게 된 점

• JOIN 쿼리의 작동 순서
  • FROM/JOIN -> WHERE -> SELECT
  • 평소에 복잡한 join 쿼리를 작성할 때 join된 테이블의 형태를 생각하고, 그 테이블에 조건을 거는 방식으로 생각하기도 했었는데 실제 쿼리 최적화가 돌면 다른 순서로 동작할 수 있다는 것을 알았다.
• 애플리케이션 코드단에서는 주로 ORM을 사용하고 raw query를 팀에서 지양하다보니 잊고있었던 내용들을 복습할 수 있었다.

어려웠거나 궁금했던 점

• 지금 팀에서는 배포시 히스토리와 롤백대비를 위해 DML, DDL을 관리하는 것 외에, 조회용 쿼리를 팀 차원에서 공유 및 관리하거나 유지보수하는 케이스는 없는데 유관부서와 공유용 데이터를 추출하는 등 자주사용하거나 중요한 조회용 쿼리를 팀 차원에서 관리하는 경험이 있으신지 궁금합니다!

업무와 관련된 내용

기타

[gusdn7142]

생각해 보지 못했는데, 공유용 데이터(+조회 쿼리)를 팀 차원에서 관리하는것도 좋은 의견 같습니다~~!

[sylee6529]

저희도 각자 로컬에서만 관리합니다.. 공유하면 정말 좋을 것 같긴하네요

[gonasooc]

오늘 서버 개발자분한테 물어봤는데, 연말에 어워드 관련된(매년 반복되는) 조회 쿼리를 따로 관리한다고는 하셨습니다

[witch-factory]

새롭게 알게 된 점

• 새롭게 알게 되었다기보다는 db 수업에서 들었던 것들을 복습하는 느낌이었다.

어려웠거나 궁금했던 점

• 강의를 듣기 시작하면서, 백엔드 개발자들에게 왜 ORM이 있는데 쌩 쿼리가 그렇게 중요하냐고 물어봤음. 그랬더니 ORM의 장점이 뭐냐? 고 묻길래 뭐 다들 아는 DB 바꿔도 똑같이 쓸 수 있고...그런 걸 말했는데 생각보다 그럴 일이 별로 없다는 이야기를 들었다. DB를 바꾸는 건 상당히 큰 일인데 그런 일이 있을 정도면 ORM이 문제가 아닐 거라고.. raw query를 쓰는 일이 꽤 많다.

업무 관련 내용

저는 스타트업에 다니고 있기 때문에 매일같이 raw query로 된 마이그레이션 sql이 메신저에 올라옵니다... raw query 많이쓴다..

[mixxeo]

말씀하신 것처럼 DB를 아예 갈거나 그런 일이 흔하지는 않을 것 같은데..ㅎㅎ 결국 ORM들도 한계가 있어서 고도화된 쿼리는 지원하지 않는 경우가 있고, 그러면 raw query를 코드단에서도 작성해야 하는 경우가 종종 있습니다. ORM으로 작성하더라도 쿼리 속도가 너무 느려서 raw query로 추출한 다음에 실행계획을 돌려보는 경우도 raw query에 대해서 잘 알아야하기도 하구요!

[SANGWOO-JOO]

새롭게 알게된점
데이터 정규화에 따라 나누어 저장하여 데이터를 관리합니다!!! 정규화를 통해 데이터 중복을 최소화 합니다.!!
분리된 테이블에서 의미있는 정보를 얻으려면 데이터를 얻으려면 데이터를 다시 연결해야합니다.
조인은 여러 테이블에 흩어진 데이터를 기본키와 외래키를 기준으로 합쳐서 보여주는 기술입니다.

이런 조인에는 내부 조인과 외부 조인으로 나누어 집니다.
내부 조인은 두테이블에 공통(교집합)으로 존재하는 테이블 결과를 보여주는 기술이고
외부 조인은 조인 시 테이블 중 한쪽 테이블을 한쪽이나 모든 테이블을 포함하여 보여줍니다. 외부 조인 시 데이터가 없으면 NULL로 반환됩니다.

어려웠던 점
아직까지 부모 <-> 자식 관계 테이블 설정을 설계하는게 논리적으로 헤깔릴 때가 있습니다.