2. 왜 관계형 인지?

1. CRUD

• 데이터베이스의 본질은 CRUD이다.
  데이터를 다루는 것만으로는, 그래프를 그리거나(시각화) 사칙연산을 하거나(연산), 데이터를 남에게 보내거나(네트워크), 임의로 합치는 등의 작업은 할 수 없다.

• 데이터베이스로 할 수 있는것은 딱 4가지.

1. Create 생성

2. Read 읽기, 조회

3. Update 수정, 변경

4. Delete 삭제

   하는 것 뿐이다. 너무 간단한 기능이지만, 이를 토대로 모든 기능을 사용할 수 있다.
   또 데이터베이스는 CRUD를 하는데에 있어서 오류가 발생하지 않고 신뢰도 있게 처리하도록 만들어져 있다. 사용자는 데이터베이스를 믿고!!(무결성) 뭐든 할 수 있는 상황이 된다.

• CRUD하는 법: 생활코딩 MYSQL강의 듣고 오기 -> https://opentutorials.org/course/3161

2. 관계형 데이터베이스를 만드는 이유

위와 같은 데이터를 쪼갠다고 했을 때, 관계형으로 데이터를 만드는 방법과 아닌 방법이 있다. 서로 비교해보자.

방법1. 세로로 짧게 하기(관계형 X)

-> 방법1에 대한 평가

장점 : 세로로 짧아지기 때문에, 레코드의 양이 줄어든다. 숙소의 편의시설이라는 것이 다 비슷비슷 하기때문에 O,X로만 표기해줘도 큰 문제는 없을 것 같다.

단점 : 숙소의 편의시설이라는 것은, 언제든지 추가,삭제,변경 될 수 있는 항목이다. 테이블의 필드가 바뀐다는 것은 단지 내부의 데이터들이 변경된 다는 것만을 의미하지 않는다. 필드가 변경되면 이에 따라 데이터베이스를 읽어오는 Query문을 변경해야하고, Query문이 변경되면 이에 따라 작성했던 코드도 변경해야 한다. 이는 지금 잠깐 편하자고 이후의 약점을 만들어두는 방식이다. 때문에 적어도 데이터베이스에서는, 이런 식으로 가로필드를 길게 하는 것은 가능한 한 지양해야 한다.

방법2. 가로로 짧게 하기

-> 방법 2에 대한 평가

장점 : 가로로 짧아지고, null인 데이터가 없다. 편의시설이나 숙소에 변경사항이 있으면 레코드를 CRUD 하는 것으로 해결이 된다.

단점 : 숙소의 숫자와 편의시설의 데이터가 많아지면, 곱연산으로 늘어나기 때문에 레코드의 숫자가 세로로 엄청나게 많아질 수 있다.

결론

필드들이 절대! 네버! 변경되지 않는다면, 가로로 긴 테이블도 충분히 고려할만한 방법이다.
하지만 현실세계에서는 절대! 라는 믿지 않는 것이 좋다고 생각한다.

기타 - 카테고리 관리

방법 1이나 2와 같이 테이블을 만든다고 했을 때는 각 편의시설들이 어떤 카테고리에 분류되어 있는지에 대해서는, 편의시설 - 카테고리 테이블을 참조해야한다. 다만 이는 여러개의 카테고리에 동일한 편의시설이 존재하지 않다고 가정하고 만들어진 테이블이다.
숙소에 동일한 편의시설이 여러개의 카테고리 내에 있다고 하면 (ex. 욕실-드라이어, 침실-드라이어) 이를 구분하는 방법은, 동일한 이름의 다른 ID를 갖는 편의시설을 만들어서 구분하는 것이다. 다만 이는 중복되지 않는 데이터를 최대한 없애고자 하는 원칙에 어긋나는 것으로 보인다. 하지만 모든 중복을 없애기 위해 테이블을 최대한 여러개로 만들어서 관리하는 것은 프로그래밍적으로는 너무 지난한 일이 될 것 같다. 어디까지 테이블을 쪼개고, 어디까지 적당히 만들어서 관리할 지는 만드는 사람들의 선택이 될 것이다.