173만명의 커뮤니티!! 함께 토론해봐요.
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
학생들이 문제를 푸는 시스템을 만들고 있는데요. 문제 갯수도 시험마다 다르고, 각 문제마다 학생들이 저장하는 답변도 달라지니까 이게 관리가 어렵더라고요. 정규화로는 좀 어려운거 같은데.. 혹시 이런경우에 JSON 넣어도 되나요? 그리고 찾아보니까 Postgresql에서 JSON을 지원한다고 하는데 이거 써서 개발하는게 맞는 판단인지 궁금합니다. 혼자서 판단할수 있음 좋겠지만 이제 막 개발배워서 해보는거라 이게 맞는지 모르겠어요.
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
안그리면 혹시 관계같은거 설정하고 나중에 참고할때 문제가 될 수 있나요? 제 기준으론 orm에서 그냥 1:N N:N 1:1 설정해놓으면 이것만 보고도 별 문제가 없긴 한데요. (엔티티 6개 수준이에요) 엔티티가 10개가 넘어가고 관계 설정이 여러개가 진행되도 ERD 없이 진행해도 괜찮나요?
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
지금 제가 개인적으로 혼자 만들고 있는 프로젝트가 있습니다. 그냥 아이디어만 갖고 시작한건데요. 아래와 같은 순서로 만들고 있습니다. (1) GPT한테 내가 원하는 기능을 설명한다. (2) GPT한테 View 먼저 그려달라고 한다. (3) View는 데이터 바인딩 안하고 그냥 하드코딩한다. (4) View 보고 GPT랑 토의하면서 기능을 기획한다. (5) 완성된 View를 보고 DB 모델링 한다. (보통 엔티티 하나나 두개정도가 됩니다) (6) 백엔드를 붙인다. 이렇게 해서 하나씩 만들어나가고 있는데요. 이거 잘못된 방법이에요? 그냥 그때그때 DB 모델링에 필요한 컬럼이 생긴다고 하면 넣어주고 빼고 하면서 만들고있거든요.
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
안녕하세요. 수업 잘 듣고 있습니다. 감사합니다. JSCODE 게시판에서 댓글 관련된 설계에서 아래와 같은 댓글 구조는 어떤 식으로 설계 할 수 있을까요? (댓글의 재댓글) *아래는 수업내용입니다.
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
안녕하세요, 선생님. 강의 감사히 잘 보고 있습니다. 주문수량에 따라 재고량 반영다는 기획일시 테이블 분리는 어떻게 할 수 있을까요? (다른 질문에 답변 올려주신 것 봤는데 직접 하려니 안되서요) 현업에서 일반적으로 매입도 존재할텐데 이 경우까지 포함한다면 재고에 대한 테이블 구성은 어떻게 되는지요? 감사합니다.
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
사용자, 임무 한명의 사용자는 여러가지의 임무를 가진다. 한가자의 임무는 여러명의 사용자를 가진다. 예를들어 양치질하기는 a사용자,b사용자,c사용자로 등록할 수 있기 때문에 상품-주문테이블처럼(아래형식처럼) 테이블 분리되어야하지 않나요? 임무 no 임무명 임무설명 데드라인 1 청소하기 청소하기 1.27 2 빨래하기 청소하기 1.27 사용자-임무 no 임무명 (외래키) 사용자(외래키) 1 1 1 1 1 2
해결됨
비전공자도 이해할 수 있는 DB 설계 입문/실전
주문할 때마다 배송 정보를 새로 입력하기 때문에 주문 정보 : 배송 정보 = 1 : 1인 건 이해했습니다. 그런데 만약 주문할 때마다 배송 정보를 기본적으로 새로 입력하기는 하지만, 이전에 사용했었던 배송지를 다시 불러오는 기능이 있고, 기본 배송지를 설정하는 기능도 있다고 하면 이런 경우에도 여전히 1 : 1이라고 생각하면 될까요? 관계는 동일하고 불러오거나 기본 배송지 기능은 그냥 코드로 구현하면 되는 걸까요?
해결됨
비전공자도 이해할 수 있는 DB 설계 입문/실전
만약 이렇게 색깔 컬럼에 RED 같은 걸 넣지 않고, #325645 를 위와 같이 중복해서 넣는다면, 이건 진짜 중복이라고 봐야 하나요? 진짜 중복이라는 생각은 드는데, #325645는 이미 특정 색을 지정하고 있어서 이것도 true, false처럼 생각해야 하나?라는 생각도 들고 뭔가 조금 헷갈려서 확인차 질문드립니다.
해결됨
비전공자도 이해할 수 있는 DB 설계 입문/실전
만약 주문 수량에 따라 재고량에 바로 반영된다는 기획이라고 가정한다면, 주문수량을 수정 할 때 재고량도 수정해야 하는 숨은 중복 이라는 생각이 듭니다. 이 경우에도 테이블을 분리 하는 것이 맞는 걸까요?
해결됨
비전공자도 이해할 수 있는 DB 설계 입문/실전
사용자 테이블 과 팔로우 테이블 과의 관계를 다대다 관계라고 할 수 있을까요? 중간 테이블로 풀어내는 다대다 관계랑은 조금 다른 것 같아서 이런 경우에는 명칭이 어떻게 되는지 궁금합니다
해결됨
비전공자도 이해할 수 있는 DB 설계 입문/실전
안녕하세요. 강의 잘 듣고 있습니다. 입문자들은 역정규화보단 정석적인 방법대로 하는 게 좋다고 하셨는데, 실제 현업에서 오래 일을 하셨던 분들이라 해도 뭔가를 처음 설계할 땐 중복을 없애는 방식으로 설계하고, 실제로 성능 등에 문제가 생기면 그때 역정규화를 고려하나요? 역정규화 자체가 처음 설계 때는 잘 안 하는 건지 궁금합니다.
해결됨
비전공자도 이해할 수 있는 DB 설계 입문/실전
Choose Category의 UI를 보면 Create New라는 항목이 보입니다. 즉 내가 원하는 카테고리를 추가하는 기능이 있는 것으로 보이고, 내가 추가한다고 남에게도 그 항목이 보이면 안되므로, 혹은 기존의 카테고리의 아이콘이나 색깔을 바꾼다고 남에게도 적용되면 안되므로 categories 테이블에는 사용자의 FK값이 있어야 할것으로 판단됩니다. 이렇게 할 경우, tasks 테이블에서 category의 FK와 사용자의 FK를 받게 될텐데, 외래키로 받은 category에도 사용자의 FK가 포함되어 있어서 사용자 FK정보를 두 번 갖게 되는것 같습니다. 물론 task나 category에서 한 번 지정된 사용자가 변경되는 일은 없을 것으로 보이지만, 그래도 엄밀히 말하면 데이터가 중복이 되는 것이 아닌지 궁금합니다.
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
강의에서 중간 테이블이, 1칸에 1개의 정보가 불가할 때라고 듣기도 했고 N:M의 관계일때는 반드시 중간 테이블을 제작해야 한다고도 들었습니다. 저 두 가지의 경우가 같은건지 궁금합니다. N:M 관계가 아닌데도 중간테이블이 만들어질 수도 있나요?
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
안녕하세요! 강의 재밌게 잘 듣고 있습니다. 투두리스트 실습 중 궁금한 부분이 생겨서 질문 남깁니다. 저는 UI를 보고 앱 세팅에 관련된 데이터도 저장해야 된다고 생각해서 app_colors, app_typographies, app_languages 세 가지 테이블을 만들었습니다. 하지만 강의에서는 이 데이터를 따로 저장하지 않으셨는데 저장하지 않은 이유가 궁금합니다.
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
배운 내용을 적용해보면서 궁금한 점이 생겨 질문드립니다. 게시판 특성상 계속해서 게시물이 쌓이게 되어 데이터의 양이 늘어날 것이라 생각합니다. 일반적으로 게시글 상세 페이지로 들어가기 전에 페이징된 게시물 리스트를 보면 해당 게시글의 제목, 조회 수, 좋아요 수 등이 표시되기도 하는데 그렇다면 보통 현업에서는 각각의 좋아요 수 쿼리와 조회 수 쿼리를 날려서 많은 데이터들을 그때그때 full scan하도록 하는지 아니면 역정규화를 수행하여 원래 테이블에 좋아요 수나 조회 수 컬럼을 붙여 넣는지 궁금합니다.
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
True, False 같은 BOLEAN type을 안쓰고 TINYINT type을 사용하는 이유가 궁금합니다
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
ㅠㅠ
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
안녕하세요 수업을 듣다가 궁금한게 생겨서 질문드립니다~ 서브 태스크 설계는 대댓글과 같은 계층형 구조로 가져가면 될까요? 무한대댓글(네이버 카페 대댓글 구조)일 때 보통 db 설계를 어떻게 가져가나요?찾아보니 인접리스트랑, 클로저테이블 등 db 패턴이 있다는데 어떤 형태로 가져가는지 궁금합니다!
해결됨
비전공자도 이해할 수 있는 DB 설계 입문/실전
강의를 보다가 궁금증이 생겨서 질문합니다. 만약 로그인 안 한 사용자(회원X)도 볼 수 있는 게시글이라고 할 때, 조회수를 어떻게 해야하는 건가요? 로그인 한 사람(회원O)만 게시글을 볼 경우 중간테이블을 만들어 이미 봤다면 조회수를 안 올리기 위해 만든 다는 것까지는 이해했습니다. 제가 생각한 방식은 게시글에 컬럼에 로그인 안 한 사용자의 조회수 넣기(그냥 수로 관리) 로그인한 사용자의 경우는 중간테이블로 조회수 관리 데이터를 따로 관리해서 이 둘을 합산해서 총 조회수로 만든다 인데 제가 너무 복잡하게 생각한 건지, 다른 좋은 방법이 있는지 궁금합니다
미해결
비전공자도 이해할 수 있는 DB 설계 입문/실전
안녕하세요 강의 잘 듣고 있어요 다 들으면 도움이 많이 되고 설계가 재밌어 질 거 같습니다. 궁금한 점은 두 엔티티 A, B의 관계를 파악할 때 무조건 처음에 하나의 A, 하나의 B 이렇게 하나의를 붙히고 생각하면 될까요? 아니면 여러개의 A 이렇게도 생각 할 수도 있을 거 같아서요
