안녕하세요 강사님, 강사님 설명이 굉장히 상식적으로 자연스럽게 이해가 되다 보니 따로 이해가 어려운 부분 없이 강의 후반부까지 잘 따라 왔는데, 어딘가 마음속에서 걸려있던 의문점 하나가 터졌습니다. 예를 들어 35강 19:46 즈음에 카테고리 테이블에 색깔 컬럼을 진짜중복/가짜중복 을 나누는데 1. HOME의 색을 YELLOW 로 바꾸면 UNIVERSITY 도 YELLOW로 바뀌는가? -> NO 2. HOME의 색인 RED를 '빨강'으로 바꾸면 UNIVERSITY 도 '빨강'으로 바뀌어야 하는가? -> YES 이 두가지 해석이 가능할 것 같습니다.. 물론 결과론적으로 머리로는 colors 테이블을 따로 만들어 FK로 연결하는 것이 맞다는 생각이 들지만 강사님의 6가지 원칙을 차례로 따라가는데 헷갈림이 있어 질문드립니다. 감사합니다.
규칙 1에 대해서 생각이 나서 드는 의문인데요 누가 좋아요를 눌렀는지 그 컬럼이 지금 여러개의 원소가 들어가있으니까 그 컬럼만 빼서 다른 테이블에 다 만들어야하는거아닌가요? 어짜피 게시글 id는 1,2로 딱 하나하나씩 들어가 있으니까... 왜 이 중복을 밑으로 나열하는지 모르겠어여
안녕하세요, 강사님덕분에 많이 배웁니다. 공부하면서 궁금한 내용이 있어 질문드립니다. FK 값 중복은 괜찮은거지? - 예시 규칙 1의 products(판매 상품) 가게 id(FK) 값 규칙 3 내용 중, 서비스를 중심으로 동사(팔다)를 골라 엔티티간 관계를 설정할 때 예시 2 내용입니다. 가게(stores), 판매상품(products) - 하나의 가계는 여러 개의 상품을 판다(팔수있다) 여기까지 이해를 했는데, 판매상품과 가게 관계에서 왜 '하나의 상품' 이라는 표현을 하는건가요? 여러개의 상품을 판다. 라고 벌써 정의 했으면서, 왜 하나의 상품이라고 하지? 여러개의 상품은 하나의 가게에 의해 팔린다. 라고 해야 하지 않나? 그래서 1:N 관계가 되는거 아니야? 그런 생각에 질의 드렸습니다. 감사합니다ㅡ
데이터베이스에 저장해야 한가? 아닌가? 구분은 이 정보들이 자주 바뀌는 정보면 데이터 베이스에 저장을 해 놓는다. 프론트단에서 백엔드로 저 데이터를 받아와서 그때 그때 실시간으로 업데이트를 시키는 것이 훨씬 좋다? 이렇게 말씀하셨는데 고정일 경우에는 그냥 프론트 코드에서 고정 시켜서 연동하면 된다는 것으로 이해했습니다. 고정적이니까 백엔드까지 갈 필요 없이 프론트 코드에서 연동하면 된다는 것도 이해가 됩니다. 그런데 자주 바뀌면 백엔드에 저장한다? 이 말씀 자체가 이해가 안됩니다. 그러면 백엔드에서 해당 앱들에 대한 데이터들을 어떻게 연동한다는 것인지 이해가 안가요. Oauth를 통한 연동 이런 것을 말씀하시는 걸까요? 그런데 그러면 고정적일 때도 어짜피 연동은 해야하니까 백엔드에 하는 것이 맞지 않을까요? 데이터를 Db에서 주고 받는데 백엔드에서 처리하는게 맞지 않을까요? 제가 백엔드 개발자 신입이여서 자세히는 모르겠습니다. 설명 부탁드립니다.
작성자 Id가 "박재성"이여서 이게 하나라도 바뀌면 같이 바뀌어야하는 데이터 중복이여서 FK로 바꿔야한다는 것은 잘 알겠습니다. 그런데 users 테이블에서 사용자 이름은 없는데 아마 jscode가 박재성을 의미하는 것 같은데 이게 FK로 바꾸었을 때 1번 id 값을 가지니까 1로 바뀌어야하는거 아닌가요? 그런데 강사님께서는 1,2로 바꾸셨는데 그러면 똑같은 박재성이라는 사람이 아니게 되는거 아닌가요? users테이블에서도 id가 1번 밖에 없어서.. 혹시 동명이인 그런 건가요?
재성님 유투브에서 처음 뵙고 현재 ERP 및 백엔드 현업에서 근무중입니다 현업에 도움이 될까 해서 강의를 결제해서 들었는데 현재 저의 협업 수준에서는 다소 너무나 거리가 있는 강의 입니다....ㅠㅠ 기초를 좀 다지고 싶은 마음에 결제해서 약간 수강을 해보았는데 너무 낮은 수준의 강의 결제한것 같습니다 제 업무 난이도와 비교하여 낮은 수준이지 강의는 입문자들에게 매우 좋다고 생각합니다 해서... 동일한 가격대인 비전공자도 이해할 수 있는 AWS 입문/실전 으로 교환할수 있는지 문의드리고 싶습니다 약간의 강의 수강기록이 있지만.... 현재로서는 제가 도움을 받을수있는 부분이 없는 강의라서 .... 이렇게 어려운 부탁을 드립니다 혹시나 따로 소통에 필요할 경우를 대비해 메일을 첨부합니다 guswnd1380@naver.com
선생님, 안녕하세요! 이번에 DB설계 강의를 완강하였고, 좋은 강의 덕분에 DB 설계에 대한 자신감을 갖게 되었습니다. 강의 중간에 DB설계를 처음부터 너무 완벽하게 하려고 할 필요 없고, 혹시 나중에 생각하지 못한 부분이 있으면 수정하거나 추가로 반영하면 된다고 하셨는데요. 팀원들과 DB 설계 이후에 실제 개발을 시작하거나 또는 서비스를 운영하던 도중에 DB설계에 문제가 있다는 것을 알게 되면 추후에 수정해도 되는지 궁금합니다. 예를들어, DB 처음에 설계할 당시에는 정규화를 철저하게 지켜서 설계했는데, 나중에 배포해서 성능테스트 해보니까 역정규화 이외에는 성능을 개선시킬 수 있는 방법이 없는 경우라면, 이미 서비스 운영 중에 DB설계를 바꿔야할 것 같은데, 현업에서 이런 경우들이 종종 있는지 여쭤봅니다. 예전에 팀프로젝트 할때 다른 팀원분께서 ERD는 최대한 처음에 짜둔 방향에서 개발을 시작하면 수정하지 않는 것이 바람직하다고 하셔서 DB 설계를 수정하지 못한 경험이 있는데, 현업에서는 보통 어떻게 하시는지 궁금합니다.
안녕하세요. 관리자 테이블에 이메일이 유저의 이메일과 다르지 않다고 생각이 들어서 합치는 게 낫다고 생각이 들었습니다. 처음에는 유저에 그냥 합쳐서 새로운 컬럼 role로 관리하려고 했는데, 중복이 있어서 관리자 테이블엔, role 컬럼을 넣어서 user, admin 2개로 추가해서 이제 유저 테이블에서 FK로 사용하려고 하는데 이 방법은 어떨까요? (강의 너무 잘 듣고 있습니다, 제 멘토이십니다ㅎㅎ)
안녕하세요. 강의 끝까지 다 들었는데 갑자기 외래 키 부분에서 궁금한 점이 생겼습니다. DB 설계할 때 테이블끼리 관계를 맺기 위해 외래 키를 지정하잖아요? 그런데 외래 키로 지정을 안 하는 경우도 있나요? 조인 등에 사용될 속성은 있지만, 외래 키 지정은 안 해서 외래 키 제약 조건이 없도록 하는 경우도 있나요?
안녕하세요. 수업 듣다가 궁금한 사항이 있어 질문 드립니다! 중요하지 않을 수도 있는데, 사용자 테이블에서 닉네임이랑 아이디를 따로 해야 하지 않나요? UI 이미지보면 jscode123 이랑 마이페이지에 petya는 다른 것처럼 보이는데 사용자 테이블에 닉네임으로 해도 괜찮을까요?
