영상 잘봤습니다!! 제가 알고있는 개념 ERD 개념 확인겸 봤는데 도움이 많이 됐습니다 ㅎㅎ 조금 아쉬운게 있었다면, album 테이블에서 count attribute는 없어도 될꺼같습니다. (photo랑 fk로 연결되어있기때문에 count로 개수를 가져올 수 있습니다. (join과 groub by)) 백엔드의 코드상에서도 count를 관리를 하게된다면 코드상의 한줄이 추가되기때문에 조금의 귀찮음이 생깁니다(사람마다 다를 수도 있습니다 ㅎㅎ..). 또 마지막에 추가된 Share테이블의 경우도 UserID가 두개가 들어가면 조금더 편하게 데이터를 불러오게 될꺼같습니다. (누가 누구에게 공유를 했는지 알고 싶을 수도있으니까) 물론, album Pk키로 join 해서 UserID를 가져와서 보여주는 방법이 있긴한데 코드로 구현해보면 아시겠지만 (진짜로 귀찮습니다 코드의 복잡성도 올라가고). 여기서 share테이블에는 userId를 두개 넣고 album에는 count를 안넣는 이유는 간단하게 생각해보면 답이 나옵니다. 1. album 테이블은 거의 수시로 불리는 데이터이고, 거의 매번 photo table을 가져오기때문에 count라는 attribute를 관리 할 필요성이 없어집니다. 2. db에서 join으로 데이터를 가지고온다 해서 db select의 성능저하가 크지 않습니다. (pk키는 indexing이 되어있기때문에 db설정만 잘되어있다면, 거의 왠만해서는 문제가 없습니다) 3. share테이블은 수시로 불려오는 데이터가 아니고, 특정 조건에 의해 확인이 되는 데이터이기 때문에 백엔드 단의 코드(sql, 백엔드 코드) 간편성을 위해 두개가 들어가게 됩니다. 단, 이렇게 될 경우 share테이블에서 userID가 pk로 두개라면 둘중 한개의 데이터가 삭제된다면 null이 되니 이점은 유의해야 할 수도 있습니다.
소중한 피드백 감사합니다~ 이부분에 대해서 깊게 아시는게 느껴지네요 :) 네 맞습니다, 사실 Count 를 넣을까 말까 생각했는데 영상에서 설명하는 차원에서 넣었어요, 하지만 말씀하신 것 처럼 Join해서 가능하다고 설명을 드리는게 더 명확했을 것 같네요! 그리고 Share 테이블은 보내는 사람 아이디도 있으면 확실히 좋을 것 같습니다, 말씀하신 것 처럼 셀렉트하는데 성능저하가 걸릴 일이 없겠네요. Composite Key 설명하는데 포커스를 둔지라 이부분을 간과했던 것 같습니다. 다른 분들에게도 유익할만한 댓글 남겨주셔서 감사합니다, 앞으로도 기회가 된다면 이런 피드백 기대하겠습니다!
Entity: 사람, 물체, 개념(계정) Relationship: Entity-Entity 연결해주는 관계 Attribute: 사람 - 키, 몸무게, 성별 Entity 기록에 관한 attribute를 두는 게 좋다 ex 언제 계정 생성, 언제 로그인 A에 속해있는 B Entity 경우, A의 정보 레퍼런스가 필요: FK user_id 사진 entity 경우, 원본 사진이 너무 커서 썸네일 url 따로 두는 게 좋다
감사합니다! 제가 프로젝트 DB를 설계하며 다시 개념 잡고싶어서 영상을 봤는데요! 혹시 ERD 완성된 부분에서, User와 Album에서 Mandatory가 다 빠진부분으로 알려주셨는데 Mandatory가 있어야 하지 않을까요? 일단 사용자나 앨범이 있어야 공유가 가능하다거나, 포토가 있을 수 있을 것 같습니다!
앨범 엔티티를 만들 때 album_id와 name을 따로 만들어주는 명확한 이유가 있을까요..? 중복되는 앨범명을 못만든다고 설정해두었을때 name을 프라이머리키로 두면 id가 필요없지 않나싶어서요..! 뭔가 매번 만들때 user_id,album_id 이런식으로 따로 만들긴하는데 명확한 이유는 잘 모르겠어서 여쭈어봅니다 ㅎㅎ 영상 감사합니다! !!!맨날 이런 영상들 보기만했는데, 직접 만들어보고 영상보라는 한마디에 직접 해볼수 있었습니다 !👍👍ㅎㅎ
1. 앨범명 같은 것은 처음에 중복을 허용하지 않으니 PK로 써야지! 해버리면.. 나중에 중복을 허용해야하는 정책으로 변경되는 경우 테이블 수정 작업이 매우 커집니다. 그리고.. 앨범명 중복을 허용 안하긴 어렵죠. 내가 가진 앨범들 중에는 중복이 없게 할 수 있지만.. 10만명이 만든 앨범의 이름이 중복되지 않는다? 기획 관점에서 불가능한 정책입니다. 2. 더 큰 문제는 이것인데.. 앨범명은 PK로 사용하기에는 데이터 사이즈가 너무 큽니다. PK의 데이터 사이즈가 크면 JOIN 성능이나 Secondary 인덱스의 사이즈에 악영향을 주기 때문에 왠만해선 이름과 같은 컬럼에는 PK를 잘 사용하지 않아요. 예를 들면.. 앨범과 포토의 관계를 생각할 때, 앨범명이 PK가 되면 그 이름을 모든 포토 테이블의 행이 들고 있어야 해요. 매우 비효울적이겠죠! 3. PK인 컬럼은 수정하지 않도록 설계해야 합니다. 그런데 앨범명은 수정할 수 있을테니.. 이런 면에서도 적절하지 않아요.
SQLD 공부 중에 ERD에 대한 이해가 좀 떨어져서 이 강의를 들었는데 덕분에 많은 도움이 되었습니다~!!
항상감사 합니다
DB 설계에 대해 막막했는데 감사합니다.
친구 손주가듣고 엄청
반기는데요 ㅎ
와~ 넘 재밋게 실감나게
잘듣고 갑니다.
감사합니다 또 방문
하겠습니다.
오 !! 이해가 너무 잘갑니다 감사합니다 ㅎㅎ
피드백 감사합니다~ ^^ 궁금한거 있으시면 언제든 질문 주세요~
와 영상 만들어주셔서 정말 감사합니다 바로 구독했어요!!!!!
도움이 되었다니 감사하네요!!! 앞으로도 더 좋은 컨텐츠 많이 만들게요 ㅎㅎ
와~ 이해가 잘갑니다
많은 도움됩니다
감사드리며 방문은
필수입니다~
영상 잘봤습니다!! 제가 알고있는 개념 ERD 개념 확인겸 봤는데 도움이 많이 됐습니다 ㅎㅎ
조금 아쉬운게 있었다면, album 테이블에서 count attribute는 없어도 될꺼같습니다. (photo랑 fk로 연결되어있기때문에 count로 개수를 가져올 수 있습니다. (join과 groub by))
백엔드의 코드상에서도 count를 관리를 하게된다면 코드상의 한줄이 추가되기때문에 조금의 귀찮음이 생깁니다(사람마다 다를 수도 있습니다 ㅎㅎ..).
또 마지막에 추가된 Share테이블의 경우도 UserID가 두개가 들어가면 조금더 편하게 데이터를 불러오게 될꺼같습니다. (누가 누구에게 공유를 했는지 알고 싶을 수도있으니까)
물론, album Pk키로 join 해서 UserID를 가져와서 보여주는 방법이 있긴한데 코드로 구현해보면 아시겠지만 (진짜로 귀찮습니다 코드의 복잡성도 올라가고).
여기서 share테이블에는 userId를 두개 넣고 album에는 count를 안넣는 이유는 간단하게 생각해보면 답이 나옵니다.
1. album 테이블은 거의 수시로 불리는 데이터이고, 거의 매번 photo table을 가져오기때문에 count라는 attribute를 관리 할 필요성이 없어집니다.
2. db에서 join으로 데이터를 가지고온다 해서 db select의 성능저하가 크지 않습니다. (pk키는 indexing이 되어있기때문에 db설정만 잘되어있다면, 거의 왠만해서는 문제가 없습니다)
3. share테이블은 수시로 불려오는 데이터가 아니고, 특정 조건에 의해 확인이 되는 데이터이기 때문에 백엔드 단의 코드(sql, 백엔드 코드) 간편성을 위해 두개가 들어가게 됩니다.
단, 이렇게 될 경우 share테이블에서 userID가 pk로 두개라면 둘중 한개의 데이터가 삭제된다면 null이 되니 이점은 유의해야 할 수도 있습니다.
소중한 피드백 감사합니다~ 이부분에 대해서 깊게 아시는게 느껴지네요 :)
네 맞습니다, 사실 Count 를 넣을까 말까 생각했는데 영상에서 설명하는 차원에서 넣었어요, 하지만 말씀하신 것 처럼 Join해서 가능하다고 설명을 드리는게 더 명확했을 것 같네요!
그리고 Share 테이블은 보내는 사람 아이디도 있으면 확실히 좋을 것 같습니다, 말씀하신 것 처럼 셀렉트하는데 성능저하가 걸릴 일이 없겠네요. Composite Key 설명하는데 포커스를 둔지라 이부분을 간과했던 것 같습니다.
다른 분들에게도 유익할만한 댓글 남겨주셔서 감사합니다, 앞으로도 기회가 된다면 이런 피드백 기대하겠습니다!
고수들의 바둑을보는기분이였다
Entity: 사람, 물체, 개념(계정)
Relationship: Entity-Entity 연결해주는 관계
Attribute: 사람 - 키, 몸무게, 성별
Entity 기록에 관한 attribute를 두는 게 좋다 ex 언제 계정 생성, 언제 로그인
A에 속해있는 B Entity 경우, A의 정보 레퍼런스가 필요: FK user_id
사진 entity 경우, 원본 사진이 너무 커서 썸네일 url 따로 두는 게 좋다
감사합니다! 제가 프로젝트 DB를 설계하며 다시 개념 잡고싶어서 영상을 봤는데요!
혹시 ERD 완성된 부분에서, User와 Album에서 Mandatory가 다 빠진부분으로 알려주셨는데
Mandatory가 있어야 하지 않을까요? 일단 사용자나 앨범이 있어야 공유가 가능하다거나, 포토가 있을 수 있을 것 같습니다!
share 테이블에서 pk가 아니라 fk로 가야되지 않나요?? 외부 키인거같아서요
코딩으로 짜놓은 DB 데이터들을 직관적으로 정리하기위한 문서화 작업같은건가요?
코딩으로 짜놓은 데이터부터 시작하면 안됩니다~ 프로젝트 기획 단계에서확실히 데이터 구조를 먼저 설계해두고, 시각화 하는 작업이라고 생각하시면 됩니다!
트위터 erd도 궁금합니다
헛 시간되면 만들어볼게요! ㅎ
앨범 엔티티를 만들 때 album_id와 name을 따로 만들어주는 명확한 이유가 있을까요..?
중복되는 앨범명을 못만든다고 설정해두었을때 name을 프라이머리키로 두면 id가 필요없지 않나싶어서요..!
뭔가 매번 만들때 user_id,album_id 이런식으로 따로 만들긴하는데 명확한 이유는 잘 모르겠어서 여쭈어봅니다 ㅎㅎ
영상 감사합니다! !!!맨날 이런 영상들 보기만했는데, 직접 만들어보고 영상보라는 한마디에 직접 해볼수 있었습니다 !👍👍ㅎㅎ
1. 앨범명 같은 것은 처음에 중복을 허용하지 않으니 PK로 써야지! 해버리면.. 나중에 중복을 허용해야하는 정책으로 변경되는 경우 테이블 수정 작업이 매우 커집니다.
그리고.. 앨범명 중복을 허용 안하긴 어렵죠. 내가 가진 앨범들 중에는 중복이 없게 할 수 있지만.. 10만명이 만든 앨범의 이름이 중복되지 않는다? 기획 관점에서 불가능한 정책입니다.
2. 더 큰 문제는 이것인데.. 앨범명은 PK로 사용하기에는 데이터 사이즈가 너무 큽니다. PK의 데이터 사이즈가 크면 JOIN 성능이나 Secondary 인덱스의 사이즈에 악영향을 주기 때문에 왠만해선 이름과 같은 컬럼에는 PK를 잘 사용하지 않아요. 예를 들면.. 앨범과 포토의 관계를 생각할 때, 앨범명이 PK가 되면 그 이름을 모든 포토 테이블의 행이 들고 있어야 해요. 매우 비효울적이겠죠!
3. PK인 컬럼은 수정하지 않도록 설계해야 합니다. 그런데 앨범명은 수정할 수 있을테니.. 이런 면에서도 적절하지 않아요.
만드는법도 만들어 주세요
예 기회 봐서 만들겠습니다 ㅎ
@@hello-kyle 감사합니다 ^^