4주 2회차 과제 질문

책에서는 일정이 정각에 시작되어 한 시간 동안 진행된다는 전제로 타임슬롯의 시간 중복 검사를 구현했습니다. 그래서 18시 30분에 시작해서 40분동안 하는 타임슬롯의 경우, 책에 나온 질의문으로는 중복 검사가 완전히 되지 않아요. 과제는 이에 대한 구현을 내드린 거예요. 🙂

4주 1회차 과제

판단의 정보 원천을 하나로 통일하는 선택을 하셨군요. 🙂

4주 1회차 과제

is_host 는 호스트 자격 검증용, calendar 관계 데이터는 호스트 준비와 같은 상태 검증용으로 쓰시는 거군요. 🙂

4주 3회차 과제

기술 요구사항을 잘 기술하셨어요. 이 요구사항을 PostgreSQL로 구현한다면 조건부 고윳값 제약으로 충족할 수 있습니다. 🙂 조건부 고윳값 제약을 지원하지 않는 데이터베이스(예 : SQLite 등)를 사용한다면 애플리케이션 계층에서 검사하거나 다른 방식으로 데이터베이스의 고윳값 제약을 활용할 수 있지요. 예를 들어, 부킹에 이력(revision)을 저장하고, 고윳값 제약은 when, timeslot_id, revision으로 묶어서 설정한 후, 예약 상태인 부킹의 revision은 고정한다면 SQLite에서도 고윳값 제약으로 무결성을 충족할 수 있지요.

4주 1회차 과제

아하, is_host 는 신분, 자격을 다루고, 캘린더가 없거나 상태(현재는 없지만 status 등이 추가된다면)로 호스트의 활동 상태를 표현하는 거군요. 👍

4주차 과제(1회차, 5회차)

소속감이라는 관점이 신선하네요. 😃파일 삭제 기능은 실제 삭제 처리를 어떻게 할지도 고민해보세요. 여러 고려사항이 있어서 재밌는 상상의 시간을 가지실 거예요.

4주 1~5회차 과제

is_host 와 캘린더 데이터를 서비스 정책이나 기획의 용도로 구분하기보다는 서비스 안정에 초점을 두어 사용하기로 결정하셨군요. 이견은 아니고, 서비스 정책이나 기획의 용도로 이 둘을 다르게 사용하는 것도 함께 고려해보세요. 동일한 용도라면 is_host 나 캘린더 존재 중 하나로 통일하는 게 좋을 것 같은데, 버그 등이 발생했을 때 문제 원인 후보를 좁혀주거든요.postgresql의 조건부 고윳값 제약을 알고 계신 걸 보니 RDBMS에 대한 이해와 경험이 있으신 것 같네요. 👍

4주 3회차 과제

정석으로 잘 구현하셨어요. 👍SQLite에서는 동작하지 않는 방식이고, 실 서비스에서 여러 사용자가 접근하는 용도로 SQLite를 사용하지는 않지만, SQLite에서 고윳값 제약을 조건부로 적용하는 효과를 보는 방법도 한 번 고민해보세요. 가령, 버저닝(versioning)을 한다면, SQLite에서도 비슷한 효과를 볼 수 있는데, SQLite를 위해서가 아니더라도 버저닝을 활용하는 정책이나 기능이 필요하다면 고려해볼 수 있지요.

4주 1회차 과제

is_host 와 캘린더 보유의 의미를 구분하신 거군요. 명확히 다른 목적이라면 두 가지 조건 모두 필요하지요. 🙂

4주 5회차 과제

유출 위험을 안고 가는 것보다는 비용이 들더라도 바로 제거하는 결정을 하셨군요. 사용자가 많거나 사용자가 파일을 많이 올리는 상황에선 주기적으로 정리하는 동작도 상당한 비용이 발생합니다. 물론 현 단계에서 그걸 고려하는 건 오버 엔지니어링이지만, “만약 그런 경우라면 나는 어떻게 설계하거나 구현할까” 관점에서 고민해보시길 권해드려봅니다.