대강 필요한 테이블 어떤게 있다 정도만 정해놓고 쓰일 메서드 전부 작성하면서 어떤 컬럼이 필요한지 구체적으로 생각하고 생각도 수정하고 테이블부터 정의해놓으니까 자꾸 바꾸게되더라고 결국 쿼리 작성하기 좆같고 하니까 그게 구조적으로 편한 방향으로 개발하게되는거같음 잡담: 술은 빈속에 먹으면 영... - dc official Cpp
청므부터 확장가능한 테이블을 만드는게 제일 베스트인거 아냠?
신입이라 뭐 더 겪어봐얄거같긴 함. 생각보다 괜찮게 진행되고 있는거같다 - dc Cpp
차라리 기본테이블 만들어놓고 v1 v2처럼 확장되게 해야지 일일히 바꿔서 어쩔려고 ㄷ
필요하면 그래야지...ㅇㅇ - dc Cpp
관계 다이어그램 안만드노
erd 대강그려놓고... 역정규화 할것들 코딩하다보면 튀어나오더라고 - dc Cpp
음 데이터베이스 수업만 듣고 적용해본 적이 거의 없어서 뭔 느낌이지 모르겠당 - dc App
혼지 일할땐 괜찮은데 회사에 소속되어 어러명이 협업할땐 힘들어질 방식인듯.. 본인이 조금 더 희생하겠다면야 관계없지만 보통 구조를 요구사항에 맞게 fix해두고 요청사항에 따라 수정하니까.. 그때그때 공수도 다시 책정되고
흠...하긴 해당 프로젝트 백엔드가 나 혼자라서 그럴수도 있겠네. 여러명이서 할만한 작업은 아니라... 좀더 큰규모가 되면 설계에 시간을 더 들여야겠군 - dc Cpp
글에 좀 정보를 부족하게 담았나 싶긴한데 일단 서비스 운영하면서 테이블을 자꾸 바꾼다거나 하는 뜻은 아니었음. 뭔가 구현체 없이 설계하는건 그림 많이 그리는건 귀찮고... 뭔가 보면서 피드백삼아서 하는게 빠른거같아서. - dc Cpp
어차피 초기 설계단계에서 정규화 다 거치면 자연스레 확장가능한 구조가 잡혀있음. 그 상태에서 플렉시블하게 구조를 확장해나가면 되는거고 역정규화는 마지막 단계라고 생각하고있음. 역정규화로 넘어갈만한 사항도 잘 안생기는듯 하고말야
그럴수도 있겠다 나도 그랬었고 근데 시간지나면서 자연스레 바뀌게 된게 erd가 제대로 나오면 구현체(라고 하고 비즈니스 로직이라고 함)에서 수정될 껀덕지가 안생기더라. 결국 처음 수정사항이 계속 생기던건, 설계초기 엔티티 구성 단계에서 내가 놓쳤던 사항들이었던거였음
결국 치밀한 설계가 왕도려나...흠 - dc Cpp