[TIL #28] DB 구조 설계

작성 중입니다 (기억 못할까봐 틀만 작성한 초안)

웹소설 연재 주기 DB 설계 및 발표
피드백 : n을 가지고 있고 매번 계산해서 멤버십 전용 회차를 구분한다? 성능 이슈. 불안정함 존재. 차라리 open_at, close_at 일자만 저장, 활용하여 클립 하나를 가져오더라도 상태를 알 수 있게 하라.

연재 상태 5단계
(순서도 그린 거 넣기)
ㄴ 기획 회의에서 파악한 요구사항 바탕으로 설계

DB 설계 내용 발표 및 질문 - 피드백

n 을 비즈니스 로직 상에서는 활용하지 않는다? 그럼 오픈 일자 패턴 적용 및 생성 시에 수식으로 사용? 근데 연재 주기랑 기다무 주기랑 다를 수도 있는데 경우의 수로 나눠서 로직 구상?

...ㅎㅎ 또 알고리즘 문제같은 업무인가? ...난이도 이거 맞음?

=> 답이 없다 일단 상무님께 질문해서 피드백 받아보자

피드백 내용
n을 간격이라 두고 기다무 요일 이런거 싹 다 없애고 기존 open_at 이랑 연동되도록 하자 (수식 적용 느낌)
상용에 공개된 것을 벌크로 업데이트? 운영상에서 실수하면 끝날 수 있음. 그 기능 없애자. 다만 운영 편리성을 위해 insert 시 자동 패턴화...
연재 주기랑 기다무 주기랑 다를 수가 있다고? 잠시만 그건 다른 얘기인데. 기획자랑 웹 개발자님 불러서 이야기 해봅시다.
((( 이야기 중... 기획자님이 운영팀과 해당 내용 얘기해보겠다고 함. => 내일 정확한 내용 나와야 설계 확정 가능할 듯. )))
일단 그러면 지금 설계한 대로 간다고 하고 내일 이야기합시다. 테이블 column 명은 좀 더 고민해보세요.
((( 차장님과 열심히 고민중...☆ )))

중요 포인트 : 관리자가 실수 없이 직관적으로 편리하개 사용할 수 있겠는가. 비즈니스 로직 상에서 성능 이슈는 없을 것인가. 변수명이 직관적인가.


동기들과 회식있어서 퇴근 후 ㄱㄱ
언니가 그립톡 선물...! 양갈비도 언니가 (*˙˘˙)♡
재밌게 회사생활 하는 듯해서 다행!
(그립톡 사진 넣기)

집 도착 오전 0시... 현재 시간 1:36분...
내일 출근... 할 수 있겠지....^ㅁ^;;;;


현재 글 수정은 내일 또는 주말에 할 예정!


Zzz