반려견 미용 중개 서비스를 진행하면서 많은 것들을 배웠고, 그 때마다 머리가 한 번씩 트였다고 생각합니다.
이제 교육 기간도 끝났기 때문에 천천히 계속 회고를 좀 하려고 합니다.

---

데이터베이스란?

✅ 데이터를 효율적으로 **저장**하고, **관리**하고, **검색**하기 위한 **데이터 집합**

즉, 데이터를 체계적으로 저장해두고, 쉽게 찾거나 변경할 수 있도록 도와주는 공간이다.

데이터베이스의 종류

1. 관계형 데이터베이스(RDB)
   1. 테이블을 기반으로 데이터를 저장하는 데이터베이스
      1. MySQL, PostgreSQL, Oracle
2. NoSQL 데이터베이스
   1. 비정형 데이터(문서) 등을 빠르게 처리하기 위한 비관계형 데이터베이스
      1. MongoDB, Redis
3. 메모리 기반 데이터베이스
   1. 데이터를 RAM에 저장해 빠른 속도로 처리
      1. Redis

✅

Redis는 NoSQL과 메모리 기반에 속하는 이유
1. NoSQL의 특성

• 고정된 테이블 스키마 없이 데이터를 저장.
• 비정형 데이터 : 키-값의 구조를 사용

1. 메모리 기반 데이터베이스의 특성

• 말그대로 메모리에 저장

RDB를 사용하는 근본적인 이유

데이터를 구조화하고, 무결성과 일관성을 유지하기 위함.

데이터 관계와 구조 관리

• RDB를 통해 우리는 데이터를 테이블로 관리하고, 이 테이블 간 관계를 정의합니다.
• 예로, 간단히 고객(Customer)이 자신의 반려견(Puppy) 데이터를 저장하고, 디자이너(Designer)에게 견적서(Estimate)를 보낸 과정을 연결하면, 추후 고객이 자신의 어떤 반려견이 어떤 디자이너에게 어떤 내용의 미용을 받았는지 쉽게 추적이 가능하다는 겁니다.

데이터 무결성과 일관성을 보장

• PK, FK, NOT NULL 등으로 무결성의 원칙을 지킬 수 있다는 것입니다.
• 이를 통해 데이터를 신뢰성있게 저장하며 잘못된 데이터가 들어오는 것을 방지합니다.
• 트랜잭션과 락을 통해 많은 사용자가 동시에 데이터를 읽고 쓰는 상황일 때 데이터의 불일치가 발생하지 않도록 하여 일관성을 보장합니다.

복잡한 쿼리를 실행할 수 있다.

• 리뷰 ID를 이용해 estimate_proposal의 ID, estimate의 ID, bidding의 ID, Designer ID, Workspace의 ID를 차례대로 찾아가 해당 미용실에 적힌 리뷰를 전체 조회할 수 있다.

언제 RDB를 사용해야 하는가

• 데이터가 명확히 정의된 관계가 필요한 경우
• 데이터의 무결성과 트랜잭션 안정성이 중요한 경우

정합성은 왜 중요한가

• 말그대로, 데이터가 모순 없이 일관된 상태를 유지하는 것을 정합성이라고 말한다.
• 당연히 이 정합성이 깨지면 일관성이 깨졌다는 것을 의미하며, 이는 데이터베이스가 망가졌음을 의미한다.
• 예로, 은행 DB를 만들었다고 가정했을 때, 고객 계좌에서 돈을 인출한 기록이 있는데 잔액이 갱신되지 않았다면 큰 문제가 발생한다. 돈복사버그가 터졌다고 할 수 있겠다.
• 반려견 미용 서비스에서도, 만일 반려견의 테이블이 문제가 생겼을 때, 그러니까 반려견 테이블에서 실수로 반려견을 삭제했다고 가정해보겠습니다. “그러면 여기다가 반려견 추가만 하면 되겠지?”라고 생각하면 더 큰 문제가 발생할 것입니다. 이 반려견 테이블은 단독 관계를 가진 테이블이 아니라 가장 가깝게는 고객의 테이블과 연관이 되어 있을 것입니다. 고객 키만 추가하면 되는가? 그것도 아닙니다. 이전 반려견이 미용을 진행했을 때 estimate와 견적 프로세스, 견적 스레드가 있을 것입니다. 그에 대해서도 다시 관계를 정의해줘야 할 것이며, 그 견적을 진행했던 미용사, 미용실, 그리고 추후 작성했던 리뷰까지도 다 손을 봐야한다는 것이죠. 만일 그렇지 않았을 때, 추후 미용실에서 리뷰 전체를 조회한다고 했을 때, 리뷰는 있는데 반려견이 없을 수도 있겠고, 리뷰 자체를 찾아오지 못해서 해당 API가 익셉션을 터뜨릴 수도 있을 것입니다.
• 이게 실제 시행되는 서비스가 아니라 시범 운영했던 서비스였기 때문에 해당 문제는 여기까지에서 멈출 수 있었지만, 이게 실제 재화가 오고가는 그러한 범주의 서비스였다면 법적 책임을 물수도 있을 것입니다. 그러니까 DB는 소중하게 다룰 수 있어야한다는 것입니다.
• RDS의 주요 특징이 뭐였다고 했죠? 데이터들을 서로 관계를 맺을 수 있었다는 것이죠.
• 즉, 우리가 사용하는 RDB는 많은 테이블들이 서로 단독적으로 있는 것이 아니라 관계를 맺고 있을 확률이 너무나도 높다는 것입니다.
• 서비스를 만들었을 때 시스템은 서로 상호작용을 하고 있을 것이다. 하나의 테이블이라도 어긋나는 데이터가 들어오게 되면 다른 테이블까지 연달아 정상 작동할 수 없을 확률이 매우 높아지며, 이는 더 나아가 데이터베이스를 초기화해야 하는 문제가 발생할 수 있을 것입니다.
• 그렇기 때문에, 더미 데이터로 서비스가 정상작동하는지를 알아보기 위해서는, 하나의 테이블에만 데이터를 넣는 것이 아니라, 그 테이블에 관계된 테이블까지도 고려해서 연관되게 데이터를 집어넣을 필요가 있습니다. 예로, 우리 프로젝트에서 미용견 서비스가 정상작동하는지 확인을 하기 위해 더미데이터를 집어넣었는데, 리뷰 API가 작동하는지 파악하기 위해 프로세스를 열고 스레드를 완성시키는 행위만 했습니다.
• 이 때 문제가 생긴것은 분명 estimate 테이블까지도 연관이 되어 있는데, 프로세스, 스레드에 대해서만 생각을 해서 문제가 생겼습니다. 나중에 검증 로직을 진행할 때 프로세스, 스레드, estimate가 존재할 때 추후 견적서를 조회할 수가 있었는데, estimate가 없으니까 찾을 수 없는 견적서라고 exception이 터져버린 것입니다. 저는 단순히 리뷰 도메인만을 생각했어서 thread가 완료만 된다면 아무 일이 없을 줄 알았는데 이 데이터베이스에서 테이블 간의 관계를 진지하게 생각하지 않았던 탓입니다.