Database 설계 방법

제일 중요한데 달달 외운 이론은 잘 얘기하면서 설계할 때 뭔지 모르는 사람 너무 많아서 기록

Transaction (트랜잭션)

여러 개의 클라이언트가 동시에 액세스한거나, 데이터 처리가 중단되는 경우 데이터 부정합을 방지

금융 거래에 비교하기

• 송금할 때,
  • A 계좌 잔액을 불러온다.
  • B 계좌 잔액을 불러온다.
  • A 계좌에서 1만원 인출하는 기록을 저장한다.
  • B 계좌에서 1만원 입금하는 기록을 저장한다.
  • A 계좌 잔액을 저장한다.
  • B 계좌 잔액을 저장한다.

즉, 6개의 메서드(기능)를 각각 만들더라도, 트랜잭션을 열고 닫는 사이 6개의 기능이 모두 동작해야한다.
또, C라는 다른 고객과 B가 거래를 하더라도 위 A, B 사이의 거래에는 문제가 생기지 않아야한다.

ACID 원칙

• Atomicity (원자성): 중간 단계까지 실행되고 실패하는 일이 없어야 한다.
• Consistency (일관성/정합성): 트랜잭션 전후의 데이터베이스 규칙은 같아야 한다.
• Isolation (독립성): 트랜잭션은 서로 독립적이어야 한다.
• Duration (지속성): 트랜잭션에 대한 로그는 영구적으로 남아야 한다.

금융 거래에 비교하기

• Atomicity: 1만원 송금 시, 성공하거나 실패만 남아야함. (5천원은 성공하고, 5천원 실패하고 그런거 없음)
• Consistency: 1만원 송금 시, 송금 전 후 내 신상이 바뀌지는 않음. (송금 전 남자였는데, 송금 후 여자라거나 그런거 없음)
• Isolation: A에게 1만원 송금, B에게 1만원 송금했다고 둘 중 하나에게 다짜고짜 2만원 줬다고 할 수는 없는 노릇.
• Durability: 시스템 오류든, 사람 오류든 1만원 송금 완료 시, 기록이 남아야 함. "난 보냈는데요" 라고 말로만 할 수는 없는 노릇.

트랜잭션 고립성 수준(Isolation Level)

• TODO.

Q&A

• DB에서 Table 이름을 변수(Variable)로 사용해도 되나요?
  • 사용해도 되지만, 권장되지 않는 방법입니다.
  • 보안(SQL Injection 취약), 가독성 및 유지보수, 최적화 또는 성능 문제와 관련이 있습니다.