#설계 #table #database #쉬운코드 데이터베이스느 백엔드에서 매우 중요하죠 특히 한번 설계하고 데이터가 쌓이기 시작하면 다시 구조 변경하는 쉽지가 않습니다 그래서 처음 DB 스키마 설계가 대단히 중요한데요, 오늘은 테이블 설계를 잘못했을 때 어떤 문제가 있는지 집중적으로 살펴봅니다~!
설명을 듣다보니 document 형 DB (ex. mongodb) 의 경우가 예제로 설명하신 잘못 설계한 (중복된 데이터가 존재하는) table 과 비슷하게 동작하는거 같은데요. rdb 는 테이블을 분리해서 이런 문제를 해결하는데, 그럼 mongodb 와 같은 경우에는 중복된 데이터 (ex. debt_leader_id) 가 수정될 경우, 모든 데이터에 대해 update 를 쳐줘야 하나요..?
강의 봐주셔서 감사합니다 :) 조인했을 때 가짜 데이터가 생기는 이유는 테이블 설계를 잘못했기 때문이라서, 테이블 설계 잘못하면 네추럴 조인 외에도 조인 할 때 발생할 수 있습니다ㅠㅠ (영상의 예제에서 project_location으로 명시해서 여러 조인을 해보면 같은 현상이 발생한다는 것을 보실 수 있어요)
질문을 드려도 될까요? 쇼핑몰에서 회원 주소가 있고, 배송지 테이블이 회원 번호를 배송지의 외래키로 잡은 상태에서 처음에는 A주소로 보낸 후 주소가 변경돼서 B주소로 바꾸게 되면 기존 A주소로 보냈던 주소가 B주소로 변경이 될텐데요.. 만약 한번이라도 주소가 사용된 상태라면 주소지 변경이 불가능하게 만들어야 하나요? 아니면 변경이 아니라 신규주소를 받아서 두번째 배송지로 결정해 해야 하나요? 비단, 이런 문제뿐만 아니라, 테이블을 쪼개는 상황이라면 이런 상황이 벌어질텐데..어느 부분을 공부하고 이해해야 하는지 잘 모르겠습니다.
안녕하세요~ 주신 질문의 경우에는 서비스 스펙에 따라 달라질 것 같아요~ 서비스에서 배송마다 주소지 입력을 받을 것인지, 아니면 최초 DB에 입력된 주소를 그대로 쓸 것인지 등등의 정책적인 부분은 서비스 스펙을 정할 때 같이 결정해줘야 하는 부분 같고요, 그 결정에 따라 DB 설계를 어떻게 할지도 가이드라인이 나올 것 같습니다
관심사의 분리는 어디서나 중요한 것 같습니다. 좋은 영상 감사합니다!
설명이 너무깔끔하고 이해하기 쉬워요!
참 영상이 쉽고 빠르게 전개되니 넘 좋네요
목소리 딕션이 좋으셔서 말씀하시는 내용이 다들리네요. 깔끔하게 내용 정리도 되어 이해하기 쉽습니다!
저도 제일 궁금했던 부분인데 감사합니다 ㅎㅎ 가짜데이터가 발생할수 있다는거까지는 생각을 못했네요!!
이게 참 신기하더라고요
테이블 잘못 나누면 다시 조인했을 때 무에서 유를 만들 수 있습니다 ㅎㅎ
이해가 너무 잘되네요 감사합니다 :D
크~!! 댓글 감사합니다 :)
재미있게 잘 봤습니다! 감사해요!
안 그래도 최근에 궁금했던 부분인데 이렇게 영상으로 나오다니..ㅎㅎ 항상 감사합니다! 🙏
오오~~ 타이밍이 딱이었네요 !!ㅎ
항상 애청해 주셔서 감사합니다 :) 👍
15:20 5,6번째 튜플이 가짜 정보인걸 어떻게 알수있죠? 1,3번째 튜플이 가짜 정보일 수도 있는거 아닌가요?
강의 너무 잘 보고 있습니다. 최근에 공부하다가 조인이 몇개 이상이면 안된다 그렇다면 설계가 잘못된것이다 라고 들었습니다. 마지막에 말씀해주신 성능상의 문제와 테이블을 나눠야 한다 이 두가선택지 중 적정선을 구해서 설계를 해야 하는것이 맞을까요 ?
네, 맞습니다~ 적절한 선을 잘 타는게 중요할 것 같아요 👍
@@ez. ㅠㅠ 뭐든지 트레이드 오프군요 감사합니다 ㅎㅎㅎ :)좋은 강의 잘보고있습니다
김영한도 그렇고 경상도분이 강의를 잘하시네
null 값은 적게 쓰는 것이 좋다
하나의 관심사 - 하나의 테이블. FK 키로 연결 -> 불필요한 null X
좋은 영상 감사합니다 ㅜ
설명을 듣다보니 document 형 DB (ex. mongodb) 의 경우가 예제로 설명하신 잘못 설계한 (중복된 데이터가 존재하는) table 과 비슷하게 동작하는거 같은데요. rdb 는 테이블을 분리해서 이런 문제를 해결하는데, 그럼 mongodb 와 같은 경우에는 중복된 데이터 (ex. debt_leader_id) 가 수정될 경우, 모든 데이터에 대해 update 를 쳐줘야 하나요..?
테이블에 스키마라고 하시는 것 보다 테이블에 컬럼 또는 엔티티에 속성으로 표현하셨으면 더 좋지 않았을까 생각듭니다.
좋은 강의 강사합니다 선배님~!
제가 선배님 플레이리스트 중에 내맘내고 백발백중강의로 공부중인데 혹시 공부 내용 간략히 정리해서 tistory에 업로드해도 괜찮을까요? 출처로 유튜브 주소는 남길예정인데 먼저 허락을 받아야 할것 같아서 댓글남깁니다~~!
영상 봐주셔서 감사합니다 :) ㅎㅎ
넵 괜찮습니당! 링크만 걸어주시면 채널 홍보도 되고 좋죠 👍
강의 감사합니다! 질문있습니다! 혹시 네츄럴 join 외 left join, right join등의 outer join 또는 inner join도 가짜 데이터가 생길 수 있나요?
강의 봐주셔서 감사합니다 :)
조인했을 때 가짜 데이터가 생기는 이유는 테이블 설계를 잘못했기 때문이라서, 테이블 설계 잘못하면 네추럴 조인 외에도 조인 할 때 발생할 수 있습니다ㅠㅠ (영상의 예제에서 project_location으로 명시해서 여러 조인을 해보면 같은 현상이 발생한다는 것을 보실 수 있어요)
감사합니다
질문을 드려도 될까요? 쇼핑몰에서 회원 주소가 있고, 배송지 테이블이 회원 번호를 배송지의 외래키로 잡은 상태에서 처음에는 A주소로 보낸 후 주소가 변경돼서 B주소로 바꾸게 되면 기존 A주소로 보냈던 주소가 B주소로 변경이 될텐데요.. 만약 한번이라도 주소가 사용된 상태라면 주소지 변경이 불가능하게 만들어야 하나요? 아니면 변경이 아니라 신규주소를 받아서 두번째 배송지로 결정해 해야 하나요? 비단, 이런 문제뿐만 아니라, 테이블을 쪼개는 상황이라면 이런 상황이 벌어질텐데..어느 부분을 공부하고 이해해야 하는지 잘 모르겠습니다.
안녕하세요~
주신 질문의 경우에는 서비스 스펙에 따라 달라질 것 같아요~
서비스에서 배송마다 주소지 입력을 받을 것인지,
아니면 최초 DB에 입력된 주소를 그대로 쓸 것인지 등등의 정책적인 부분은 서비스 스펙을 정할 때 같이 결정해줘야 하는 부분 같고요,
그 결정에 따라 DB 설계를 어떻게 할지도 가이드라인이 나올 것 같습니다
00:00
08:20
10:20
우린 이걸 정규화? 하기로 했어요가 맞나요?
네~ 맞습니다 👍
중복 데이터를 저장하는 것을 최소화하기 위해서 정규화를 수행합니다
디비 설계를 얼마나 잘했느냐에 따라 개발이 쉽고 어렵다..ㅠㅠ
맞아요 테이블 설계를 어떻게 했느냐에 따라 나비효과가 엄청나죠
따봉b
😄👍
자 그러면 오늘도 고고싱
ㅋㅋㅋㅋㅋㅋ 고고싱!! 👍