[🚀 DB - 실습] 클라우디 미션 제출합니다.

[bel1c10ud]

3월 18일 예비군 훈련으로 인해 출석하지 못해 PR이 없어, 별도로 PR을 생성하였습니다.

🤔 생각해 보기

SQL 실습 관련

1. 기본키란 무엇이고 왜 필요한가?

기본키는 각행을 가리키는 고유한 식별자
기본키가 없다면 같은 값으로 구성된 행이 여럿 있을때 구분할 수 없다.

2. MySQL에서 사용되는 AUTO_INCREMENT는 왜 필요할까?

매번 직접 ID를 지정하다보면 휴먼 에러가 일어날 수 도 있고, 유니크한 ID를 만들기 위해 추가 쿼리가 요구될 수 있기 때문에

3. 학생이 등교는 했지만 하교 버튼을 누르지 않았을 때, end_time에 NULL이 저장된다. NULL 값을 처리할 때 주의할 점은?

비교 연산으로 NULL을 판별할 수 없다.
집계 함수에서 NULL이 무시된다.
산술 연산시 결과가 NULL이 된다.
프론트엔드에서 NULL이 그대로 출력되지 않고 "미하교"와 같이 표시될 수 있도록 별도의 처리가 필요하다.

4. crew와 attendance 테이블의 관계를 ER 다이어그램으로 시각화해보자. 이 관계를 일상 생활의 예시로 비유한다면 어떤 것이 있을까?

고객과 주문
고객 한 명이 주문을 여러 번 할 수 있고, 고객 정보는 고객 테이블 한 곳에서 관리된다.

2026 공통강의 - DB 개념 연결

1. 출석 시스템에서 동시에 100명이 등교 버튼을 누른다면 어떤 일이 일어날까? 이 문제를 2026 공통강의 - DB에서 배운 트랜잭션과 ACID 속성으로 설명해보자

100개의 INSERT 트랜잭션이 동시에 DB에 도착
원자성으로 각 INSERT가 완전히 성공하거나 실패
격리성으로 트랜잭션끼리 간섭하지 않음
일관성과 지속성으로 제약조건과 영구 저장이 보장

2. 출석 데이터가 파일(CSV)이 아닌 데이터베이스에 저장되는 이유는 무엇일까? 파일 시스템으로 출석을 관리했다면 어떤 문제가 생길까?

CSV로 관리하면 닉네임 같은 크루 정보가 출석 기록마다 중복 저장돨 수 았음
100명이 동시에 파일에 쓰면 데이터가 덮어씌워지거나 깨질 수 있음

3. 출석 데이터를 관계형 DB가 아닌 NoSQL(예: MongoDB)로 저장한다면 테이블 구조가 어떻게 달라질까? 어떤 장단점이 있을까?

{
  "crew_id": 1,
  "nickname": "검프",
  "attendance": [
    { "date": "2025-03-04", "start_time": "09:45", "end_time": "18:10" },
    { "date": "2025-03-05", "start_time": "09:50", "end_time": "18:05" }
  ]
}

장점: 다양한 유형의 데이터를 담을 수 있다, JOIN 없이 읽을 수 있어 빠르다
단점: 구조가 불병확하고, 집계 쿼리가 복잡해진다.

🧐 더 생각해 보기 (심화)

1. 왜 crew 테이블에서 nickname을 기본키로 하지 않은 걸까? attendance 테이블에 attendance_id가 존재하는 이유는 무엇일까?

의미가 있는 값과 수정될 수 있는 값을 키본키로 사용하는 것은 적절치 않다
nickname을 인덱스 탐색에 사용하는 것은 효율적이지 않다
각 행을 가리키는 고유한 식별자가 필요하기 때문에

2. 데이터베이스 제약 조건 중 RESTRICT, CASCADE는 무엇인가?

RESTRICT: 부모 레코드를 수정/삭제할때 자식 테이블에 참조하는 행이 있다면 이를 거부한다
CASCADE: 부모 레코드가 수정/삭제되면 자식 레코드도 같이 삭제됨

3. 다음 두 쿼리는 동일한 결과를 반환하지만 성능에 차이가 있다. 어떤 차이가 있으며, 어떤 상황에서 각각 유리할까?

-- 쿼리 1: 서브쿼리 사용
SELECT * FROM attendance WHERE crew_id IN (SELECT crew_id FROM crew WHERE nickname LIKE '네%');

-- 쿼리 2: JOIN 사용
SELECT a.* FROM attendance a JOIN crew c ON a.crew_id = c.crew_id WHERE c.nickname LIKE '네%';

서브 쿼리: 쿼리를 읽기 쉽게 표현하고 싶을 때
JOIN: 두 테이블의 컬럼을 함께 SELECT해야 할 때

4. attendance 테이블을 완전히 정규화하면 어떤 장점이 있을까? 반대로 일부 비정규화를 적용한다면 어떤 쿼리 성능 이점을 얻을 수 있을까?

정규화: 크루 정보가 수정되는 경우 attendance 테이블에 기록된 해당 크루의 출석 정보를 모두 수정하지 않아도 된다.
비정규화: 출석 기록에서 크루 정보를 가져오기 위해 crew 테이블을 가져올 필요가 없다.

5. 출석 시스템이 수백 명의 사용자에 의해 동시에 접근된다면, 연결 풀링(connection pooling)은 무엇이고 왜 필요한가?

많은 리소스가 드는 연결을 맺고 끊는 과정을 생략하고 미리 연결을 미리 생성해놓고 열어놓는 개념

6. 실습에서 수행한 INSERT, UPDATE, DELETE를 하나의 트랜잭션으로 묶는다면 어떻게 작성할 수 있을까? 만약 DELETE 도중 오류가 발생하면 앞서 수행한 INSERT와 UPDATE는 어떻게 되어야 할까?

START TRANSACTION;

INSERT INTO attendance (crew_id, nickname, attendance_date, start_time, end_time)
VALUES (크루 ID, 닉네임, 출석 날짜, 등교 시간, 하교 시간);

UPDATE attendance
SET start_time = 등교 시간
WHERE crew_id = 크루 ID AND attendance_date = 출석 날짜;

DELETE FROM attendance
WHERE crew_id = 크루 ID AND attendance_date = 출석 날짜;

COMMIT;

트랜잭션으로 묶인 모든 작업이 롤백된다.