Database CASCADE와 OOP

Foreign Key와 CASCADE

• RDB에서 Table 설계 시 다른 Table의 PK를 FK로하여 Column을 생성한 뒤 CACADE 옵션을 주게되면 해당 FK를 PK로 갖고 있는 테이블의 레코드가 수정되거나 삭제 될 때 FK를 컬럼으로 갖고 있는 테이블의 레코드도 변경되거나 함께 삭제된다.

예시

User

id (PK)

name

Phone

id (PK)

user_id (FK)

number

• 위와 같이 Phone 테이블이 User 테이블의 PK(id)를 FK(user_id)로 갖고 있고, 해당 컬럼에 CASCADE 옵션이 존재한다면
  특정 유저(id=1) 레코드가 변경/삭제되면 유저 아이디(1)를 갖고 있는 Phone 테이블의 레코드도 변경 또는 삭제 된다.

---

Schema Mapping

• 일반적으로 서비스 객체와 데이터베이스 테이블 간의 매핑은 1:1 관계를 갖는다.
• 그러나 선택적으로 1:N의 관계를 갖을 수도 있다.
  
  • 데이터베이스가 아닌 서비스의 실제 객체를 중심으로 다양한 설계가 가능하다.

1:N 관계 예시

객체

User

name

phone

car

• 특정 유저 A는 이름(name)과 휴대폰(phone), 자동차(car)를 갖고 있는 객체

테이블

User

id (PK)

name

Phone

id (PK)

user_id (FK)

number

Car

id (PK)

user_id (FK)

serial_number

CASCADE를 이야기 한 이유

• 다시 본론으로 돌아와 Database의 Cascade를 꺼낸 목적은 위와 같이 1:N 관계로 객체와 테이블 스키마가 매핑될 때 Cascade 옵션이 존재한다면 서비스의 객체 중심적인 처리가 수월해진다.
  • 예를 들어 1:N관계가 아니라면 특정 유저 A가 삭제될 때 유저 A가 소유하고 있는 Phone, Car를 모두 찾아 삭제하는 작업을 개발자가 명시적으로 진행해야 한다.
  • 1:N 관계에서 실제 데이터베이스 테이블에 Cascade 옵션이 존재한다면 유저 A가 삭제될 때 Phone, Car 모두 삭제 된다.

위험한 CASCADE

• 이전 직장(S은행 전산 시스템)에서는 데이터베이스에 CASCADE 옵션을 거의 설정하지 않았다. 그 이유는 다름아닌 예기치 못한(?) 레코드 삭제를 방지하기 위함이었다.
  • 물론 해당 서비스는 객체 지향적으로 설계되어져 있지 않았기에 CASCADE를 설정하지 않은 이유가 그 당시 납득되었다.

객체 지향을 공부하면서 데이터베이스의 CASCADE를 객체 지향 프로그래밍에 활용 할 수 있는 방법을 생각하게 되었다.
다양한 패러다임을 습득하면서 서비스를 설계하는 능력을 키우는 것이 중요할 것 같다.