데이터베이스에 저장해야 한가? 아닌가? 구분은 이 정보들이 자주 바뀌는 정보면 데이터 베이스에 저장을 해 놓는다. 프론트단에서 백엔드로 저 데이터를 받아와서 그때 그때 실시간으로 업데이트를 시키는 것이 훨씬 좋다?  이렇게 말씀하셨는데 고정일 경우에는 그냥 프론트 코드에서 고정 시켜서 연동하면 된다는 것으로 이해했습니다. 고정적이니까 백엔드까지 갈 필요 없이 프론트 코드에서 연동하면 된다는 것도 이해가 됩니다. 그런데 자주 바뀌면 백엔드에 저장한다? 이 말씀 자체가 이해가 안됩니다. 그러면 백엔드에서 해당 앱들에 대한 데이터들을 어떻게 연동한다는 것인지 이해가 안가요. Oauth를 통한 연동 이런 것을 말씀하시는 걸까요? 그런데 그러면 고정적일 때도 어짜피 연동은 해야하니까 백엔드에 하는 것이 맞지 않을까요? 데이터를 Db에서 주고 받는데 백엔드에서 처리하는게 맞지 않을까요? 제가 백엔드 개발자 신입이여서 자세히는 모르겠습니다. 설명 부탁드립니다.

작성자 Id가 "박재성"이여서 이게 하나라도 바뀌면 같이 바뀌어야하는 데이터 중복이여서 FK로 바꿔야한다는 것은 잘 알겠습니다. 그런데 users 테이블에서 사용자 이름은 없는데 아마 jscode가 박재성을 의미하는 것 같은데 이게 FK로 바꾸었을 때 1번 id 값을 가지니까 1로 바뀌어야하는거 아닌가요?그런데 강사님께서는 1,2로 바꾸셨는데 그러면 똑같은 박재성이라는 사람이 아니게 되는거 아닌가요?users테이블에서도 id가 1번 밖에 없어서.. 혹시 동명이인 그런 건가요?

UI를 보고 저장해야 하는 데이터인지, 그냥 넘어가도 되는지, 혹은 UI를 봐도 어떤게 DB테이블에 들어가야 하는지 감이 안잡힐때 어떤 기준이나 팁이 있을까요? ㅜㅜ

재성님 유투브에서 처음 뵙고 현재 ERP 및 백엔드 현업에서 근무중입니다현업에 도움이 될까 해서 강의를 결제해서 들었는데현재 저의 협업 수준에서는 다소 너무나 거리가 있는 강의 입니다....ㅠㅠ기초를 좀 다지고 싶은 마음에 결제해서 약간 수강을 해보았는데너무 낮은 수준의 강의 결제한것 같습니다제 업무 난이도와 비교하여 낮은 수준이지 강의는 입문자들에게 매우 좋다고 생각합니다해서... 동일한 가격대인 비전공자도 이해할 수 있는 AWS 입문/실전으로 교환할수 있는지 문의드리고 싶습니다약간의 강의 수강기록이 있지만.... 현재로서는 제가 도움을 받을수있는 부분이 없는 강의라서 ....이렇게 어려운 부탁을 드립니다혹시나 따로 소통에 필요할 경우를 대비해 메일을 첨부합니다guswnd1380@naver.com

선생님, 안녕하세요!이번에 DB설계 강의를 완강하였고, 좋은 강의 덕분에 DB 설계에 대한 자신감을 갖게 되었습니다.강의 중간에 DB설계를 처음부터 너무 완벽하게 하려고 할 필요 없고, 혹시 나중에 생각하지 못한 부분이 있으면 수정하거나 추가로 반영하면 된다고 하셨는데요.팀원들과 DB 설계 이후에 실제 개발을 시작하거나 또는 서비스를 운영하던 도중에 DB설계에 문제가 있다는 것을 알게 되면 추후에 수정해도 되는지 궁금합니다.예를들어, DB 처음에 설계할 당시에는 정규화를 철저하게 지켜서 설계했는데, 나중에 배포해서 성능테스트 해보니까 역정규화 이외에는 성능을 개선시킬 수 있는 방법이 없는 경우라면, 이미 서비스 운영 중에 DB설계를 바꿔야할 것 같은데, 현업에서 이런 경우들이 종종 있는지 여쭤봅니다.예전에 팀프로젝트 할때 다른 팀원분께서 ERD는 최대한 처음에 짜둔 방향에서 개발을 시작하면 수정하지 않는 것이 바람직하다고 하셔서 DB 설계를 수정하지 못한 경험이 있는데, 현업에서는 보통 어떻게 하시는지 궁금합니다.

안녕하세요.관리자 테이블에 이메일이 유저의 이메일과 다르지 않다고 생각이 들어서 합치는 게 낫다고 생각이 들었습니다. 처음에는 유저에 그냥 합쳐서 새로운 컬럼 role로 관리하려고 했는데, 중복이 있어서관리자 테이블엔, role 컬럼을 넣어서 user, admin 2개로 추가해서 이제 유저 테이블에서 FK로 사용하려고 하는데 이 방법은 어떨까요? (강의 너무 잘 듣고 있습니다, 제 멘토이십니다ㅎㅎ)

안녕하세요. 강의 끝까지 다 들었는데 갑자기 외래 키 부분에서 궁금한 점이 생겼습니다. DB 설계할 때 테이블끼리 관계를 맺기 위해 외래 키를 지정하잖아요?그런데 외래 키로 지정을 안 하는 경우도 있나요? 조인 등에 사용될 속성은 있지만, 외래 키 지정은 안 해서 외래 키 제약 조건이 없도록 하는 경우도 있나요?

안녕하세요. 수업 듣다가 궁금한 사항이 있어 질문 드립니다!중요하지 않을 수도 있는데, 사용자 테이블에서 닉네임이랑 아이디를 따로 해야 하지 않나요?UI 이미지보면 jscode123 이랑 마이페이지에 petya는 다른 것처럼 보이는데 사용자 테이블에 닉네임으로 해도 괜찮을까요?

안녕하세요. 덕분에 DB에 대해 알아가고 있는 입문자입니다.강의와 상관없는 질문일 수도 있지만 궁금해서 여쭤봅니다.개발자 및 DB 설계할 때 엑셀을 많이 다루나요?아니면 강의 자료를 쉽게 설명하기 위해 엑셀을 하시는건가요?

id 상품명 카테고리1 잘 지워지는락스 생활 용품2 락스 생활용품3 락스 생활용품  여기서 하나의 가게에서 상품명은 달라도 되는건 이해했는데카테고리도 가게마다 다를 수 있지 않나요?

학생들이 문제를 푸는 시스템을 만들고 있는데요.문제 갯수도 시험마다 다르고, 각 문제마다 학생들이 저장하는 답변도 달라지니까 이게 관리가 어렵더라고요.정규화로는 좀 어려운거 같은데.. 혹시 이런경우에 JSON 넣어도 되나요?그리고 찾아보니까 Postgresql에서 JSON을 지원한다고 하는데 이거 써서 개발하는게 맞는 판단인지 궁금합니다.혼자서 판단할수 있음 좋겠지만 이제 막 개발배워서 해보는거라 이게 맞는지 모르겠어요.

안그리면 혹시 관계같은거 설정하고 나중에 참고할때 문제가 될 수 있나요? 제 기준으론 orm에서 그냥 1:N N:N 1:1 설정해놓으면 이것만 보고도 별 문제가 없긴 한데요. (엔티티 6개 수준이에요) 엔티티가 10개가 넘어가고 관계 설정이 여러개가 진행되도 ERD 없이 진행해도 괜찮나요?

지금 제가 개인적으로 혼자 만들고 있는 프로젝트가 있습니다.그냥 아이디어만 갖고 시작한건데요.  아래와 같은 순서로 만들고 있습니다. (1) GPT한테 내가 원하는 기능을 설명한다.(2) GPT한테 View 먼저 그려달라고 한다.(3) View는 데이터 바인딩 안하고 그냥 하드코딩한다.(4) View 보고 GPT랑 토의하면서 기능을 기획한다.(5) 완성된 View를 보고 DB 모델링 한다. (보통 엔티티 하나나 두개정도가 됩니다)(6) 백엔드를 붙인다. 이렇게 해서 하나씩 만들어나가고 있는데요. 이거 잘못된 방법이에요? 그냥 그때그때 DB 모델링에 필요한 컬럼이 생긴다고 하면 넣어주고 빼고 하면서 만들고있거든요.

안녕하세요.수업 잘 듣고 있습니다. 감사합니다. JSCODE 게시판에서 댓글 관련된 설계에서 아래와 같은 댓글 구조는 어떤 식으로 설계 할 수 있을까요?(댓글의 재댓글) *아래는 수업내용입니다. 

안녕하세요, 선생님.강의 감사히 잘 보고 있습니다. 주문수량에 따라 재고량 반영다는 기획일시 테이블 분리는 어떻게 할 수 있을까요?(다른 질문에 답변 올려주신 것 봤는데 직접 하려니 안되서요) 현업에서 일반적으로 매입도 존재할텐데 이 경우까지 포함한다면 재고에 대한 테이블 구성은 어떻게 되는지요? 감사합니다.

사용자, 임무 한명의 사용자는 여러가지의 임무를 가진다. 한가자의 임무는 여러명의 사용자를 가진다. 예를들어 양치질하기는 a사용자,b사용자,c사용자로 등록할 수 있기 때문에 상품-주문테이블처럼(아래형식처럼) 테이블 분리되어야하지 않나요? 임무 no 임무명 임무설명 데드라인 1 청소하기 청소하기 1.27 2 빨래하기 청소하기 1.27 사용자-임무 no 임무명 (외래키) 사용자(외래키) 1 1 1 1 1 2  

주문할 때마다 배송 정보를 새로 입력하기 때문에 주문 정보 : 배송 정보 = 1 : 1인 건 이해했습니다. 그런데 만약 주문할 때마다 배송 정보를 기본적으로 새로 입력하기는 하지만, 이전에 사용했었던 배송지를 다시 불러오는 기능이 있고, 기본 배송지를 설정하는 기능도 있다고 하면이런 경우에도 여전히 1 : 1이라고 생각하면 될까요? 관계는 동일하고 불러오거나 기본 배송지 기능은 그냥 코드로 구현하면 되는 걸까요?

만약 이렇게 색깔 컬럼에 RED 같은 걸 넣지 않고, #325645 를 위와 같이 중복해서 넣는다면, 이건 진짜 중복이라고 봐야 하나요? 진짜 중복이라는 생각은 드는데, #325645는 이미 특정 색을 지정하고 있어서 이것도 true, false처럼 생각해야 하나?라는 생각도 들고 뭔가 조금 헷갈려서 확인차 질문드립니다.

만약 주문 수량에 따라 재고량에 바로 반영된다는 기획이라고 가정한다면, 주문수량을 수정 할 때 재고량도 수정해야 하는 숨은 중복 이라는 생각이 듭니다. 이 경우에도 테이블을 분리 하는 것이 맞는 걸까요?

사용자 테이블 과 팔로우 테이블 과의 관계를 다대다 관계라고 할 수 있을까요?중간 테이블로 풀어내는 다대다 관계랑은 조금 다른 것 같아서 이런 경우에는 명칭이 어떻게 되는지 궁금합니다