DB 테이블 설계 잘못하면 어떤 문제가 생길 수 있을까요?

No video

DB 테이블 설계 잘못하면 어떤 문제가 생길 수 있을까요?

Рет қаралды 17,212

Күн бұрын

#설계 #table #database #쉬운코드
데이터베이스느 백엔드에서 매우 중요하죠
특히 한번 설계하고 데이터가 쌓이기 시작하면
다시 구조 변경하는 쉽지가 않습니다
그래서 처음 DB 스키마 설계가 대단히 중요한데요,
오늘은 테이블 설계를 잘못했을 때 어떤 문제가 있는지 집중적으로 살펴봅니다~!

Пікірлер: 37

@user-ms3sr8hd2b Жыл бұрын

관심사의 분리는 어디서나 중요한 것 같습니다. 좋은 영상 감사합니다!

@lineY Жыл бұрын

목소리 딕션이 좋으셔서 말씀하시는 내용이 다들리네요. 깔끔하게 내용 정리도 되어 이해하기 쉽습니다!

@sunkyoungjin7744 Жыл бұрын

저도 제일 궁금했던 부분인데 감사합니다 ㅎㅎ 가짜데이터가 발생할수 있다는거까지는 생각을 못했네요!!

@ez. Жыл бұрын

이게 참 신기하더라고요 테이블 잘못 나누면 다시 조인했을 때 무에서 유를 만들 수 있습니다 ㅎㅎ

@_7_553 2 ай бұрын

설명이 너무깔끔하고 이해하기 쉬워요!

@AstroKorea 9 ай бұрын

참 영상이 쉽고 빠르게 전개되니 넘 좋네요

@user-lb4nx3ne8q Жыл бұрын

이해가 너무 잘되네요 감사합니다 :D

@ez. Жыл бұрын

크~!! 댓글 감사합니다 :)

@joosungkwon5939 Жыл бұрын

안 그래도 최근에 궁금했던 부분인데 이렇게 영상으로 나오다니..ㅎㅎ 항상 감사합니다! 🙏

@ez. Жыл бұрын

오오~~ 타이밍이 딱이었네요 !!ㅎ 항상 애청해 주셔서 감사합니다 :) 👍

@lucaskim6077 5 ай бұрын

재미있게 잘 봤습니다! 감사해요!

@aa-ex1ol 5 ай бұрын

15:20 5,6번째 튜플이 가짜 정보인걸 어떻게 알수있죠? 1,3번째 튜플이 가짜 정보일 수도 있는거 아닌가요?

@user-mm1ge5zs5z 7 ай бұрын

null 값은 적게 쓰는 것이 좋다 하나의 관심사 - 하나의 테이블. FK 키로 연결 -> 불필요한 null X

@공습경보삐뽀삐뽀 Жыл бұрын

강의 너무 잘 보고 있습니다. 최근에 공부하다가 조인이 몇개 이상이면 안된다 그렇다면 설계가 잘못된것이다 라고 들었습니다. 마지막에 말씀해주신 성능상의 문제와 테이블을 나눠야 한다 이 두가선택지 중 적정선을 구해서 설계를 해야 하는것이 맞을까요 ?

@ez. Жыл бұрын

네, 맞습니다~ 적절한 선을 잘 타는게 중요할 것 같아요 👍

@공습경보삐뽀삐뽀 Жыл бұрын

@@ez. ㅠㅠ 뭐든지 트레이드 오프군요 감사합니다 ㅎㅎㅎ :)좋은 강의 잘보고있습니다

@Dev_pig 11 ай бұрын

설명을 듣다보니 document 형 DB (ex. mongodb) 의 경우가 예제로 설명하신 잘못 설계한 (중복된 데이터가 존재하는) table 과 비슷하게 동작하는거 같은데요. rdb 는 테이블을 분리해서 이런 문제를 해결하는데, 그럼 mongodb 와 같은 경우에는 중복된 데이터 (ex. debt_leader_id) 가 수정될 경우, 모든 데이터에 대해 update 를 쳐줘야 하나요..?

@gyomdyung 4 ай бұрын

김영한도 그렇고 경상도분이 강의를 잘하시네

@wisiasa 11 ай бұрын

좋은 영상 감사합니다 ㅜ

@user-cq3et3pn2i Жыл бұрын

좋은 강의 강사합니다 선배님~! 제가 선배님 플레이리스트 중에 내맘내고 백발백중강의로 공부중인데 혹시 공부 내용 간략히 정리해서 tistory에 업로드해도 괜찮을까요? 출처로 유튜브 주소는 남길예정인데 먼저 허락을 받아야 할것 같아서 댓글남깁니다~~!

@ez. Жыл бұрын

영상 봐주셔서 감사합니다 :) ㅎㅎ 넵 괜찮습니당! 링크만 걸어주시면 채널 홍보도 되고 좋죠 👍

@user-dn7kr2wq8k Жыл бұрын

감사합니다

@user-yl1pg3ye9g Жыл бұрын

질문을 드려도 될까요? 쇼핑몰에서 회원 주소가 있고, 배송지 테이블이 회원 번호를 배송지의 외래키로 잡은 상태에서 처음에는 A주소로 보낸 후 주소가 변경돼서 B주소로 바꾸게 되면 기존 A주소로 보냈던 주소가 B주소로 변경이 될텐데요.. 만약 한번이라도 주소가 사용된 상태라면 주소지 변경이 불가능하게 만들어야 하나요? 아니면 변경이 아니라 신규주소를 받아서 두번째 배송지로 결정해 해야 하나요? 비단, 이런 문제뿐만 아니라, 테이블을 쪼개는 상황이라면 이런 상황이 벌어질텐데..어느 부분을 공부하고 이해해야 하는지 잘 모르겠습니다.

@ez. Жыл бұрын

안녕하세요~ 주신 질문의 경우에는 서비스 스펙에 따라 달라질 것 같아요~ 서비스에서 배송마다 주소지 입력을 받을 것인지, 아니면 최초 DB에 입력된 주소를 그대로 쓸 것인지 등등의 정책적인 부분은 서비스 스펙을 정할 때 같이 결정해줘야 하는 부분 같고요, 그 결정에 따라 DB 설계를 어떻게 할지도 가이드라인이 나올 것 같습니다

@vhsshdlajs16 6 ай бұрын

테이블에 스키마라고 하시는 것 보다 테이블에 컬럼 또는 엔티티에 속성으로 표현하셨으면 더 좋지 않았을까 생각듭니다.

@user-em8lt4jv1o Жыл бұрын

강의 감사합니다! 질문있습니다! 혹시 네츄럴 join 외 left join, right join등의 outer join 또는 inner join도 가짜 데이터가 생길 수 있나요?

@ez. Жыл бұрын

강의 봐주셔서 감사합니다 :) 조인했을 때 가짜 데이터가 생기는 이유는 테이블 설계를 잘못했기 때문이라서, 테이블 설계 잘못하면 네추럴 조인 외에도 조인 할 때 발생할 수 있습니다ㅠㅠ (영상의 예제에서 project_location으로 명시해서 여러 조인을 해보면 같은 현상이 발생한다는 것을 보실 수 있어요)