55,000원
다른 수강생들이 자주 물어보는 질문이 궁금하신가요?
- 미해결데이터베이스 중급(Modeling)
seq 칼럼을 pk로 주기에 아까운 이유가 무엇인가요?
강의에서 시스템 성능에 문제가 있을 수 있다고 말씀하셨는데 pk를 사용하면 오히려 빨라지는 것 아닌가요?
- 미해결데이터베이스 중급(Modeling)
useflag 사용하는 이유
반 테이블에 UseFlag 칼럼을 추가하는 이유가 궁금합니다. 강의에서는 다음과 같은 예시를 들었습니다. "작년에 7반을 사용했는데 올해는 7반을 사용하지 않는다면 UseFlag를 false로 하면 된다. 그러면 7반에는 학생을 받지 않고 작년에 7반에 있던 학생들 정보는 다 살아있다." 반 테이블는 아래와 같이 데이터가 쌓일텐데 2018년 1학년 1반 이교준 2019년 3학년 5반 이교준 2021년 1학년 1반 이교준 올해 7반을 사용하던 2022년 1학년 7반 이교준이 입력되면 되고 만약 7반을 사용 안 하면 아무런 데이터가 입력되지 않을 텐데 UseFlag를 사용할 일이 있나요? 혹시 UserFlag를 쿼리로 어떻게 사용하시는지 보여주실 수 있나요?
- 미해결데이터베이스 중급(Modeling)
숫자 형태의 컬럼 데이터 타입 질문드립니다
안녕하세요~ 강사님 질문이 있습니다 현재 개발 중인 프로젝트에서 유지보수의 용이성을 위해 코드 테이블을 별도로 만들어서 쓰고 있는데요 예를 들어 아래와 같은 근무 상태 코드 테이블이 있으면 1 정상근무 2 휴가중 3 근무안함 사원이 정상근무 중이면 사원 테이블의 근무 상태 컬럼에는 1이 들어가는 식입니다 또 부서 정보 코드 테이블이 있다면 E8001254 인프라 부서 D1001594 마케팅 부서 A9882011 영업 부서 사원이 마케팅 부서면 사원 테이블의 부서 컬럼에는 D1001594가 들어가고 또 이메일 수신 여부 코드 테이블이 있다면 1 수신 0 거부 선택 사항에 따라 사원 테이블 해당 컬럼에는 1 또는 0이 들어가는 식입니다 이런 코드 테이블 종류가 굉장히 많은데요 코드의 데이터 타입을 일반적으로 뭘로 선언해야 할지 고민입니다 별다른 제약 사항이 없는 테이블은 코드 번호를 숫자로 표기하고 있으니 그냥 int로 선언하는 게 맞을 거 같으면서도 앞으로 추가될지 모르는 코드 번호가 반드시 숫자 형태일 거라는 확신은 없으니 (클라이언트 요청 사항이라든지) 처음부터 varchar로 선언해놓는 게 낫지 않을까? 라는 생각도 들고요 또 이메일 수신 여부 코드 테이블 같은 경우에는 무작정 int로 선언하기에는 프로그램에서 int 변수의 초기값이 0이다 보니 특정 상황에서는 변수값을 직접 바꿔줘야 하는 번거로움이 있긴 합니다 그래서 숫자 형태지만 확장성을 생각하면 varchar로 선언하는 게 맞지 않나 고민입니다 그리고 구글링을 하다가 문자형 타입보다는 숫자형 타입이 속도가 더 빠르다고 본 것 같아서... 데이터가 많아지면 타입이 검색 속도에 영향을 끼칠까? 하는 궁금증도 있습니다 관련하여 강사님의 의견을 듣고 싶습니다 감사합니다
- 미해결데이터베이스 중급(Modeling)
PK관련 질문
. 안녕하세요 강의에서 강의개설을 위와 같이 정의하시고, PK를 Seq를 사용하지 않는 이유는 성능상의 문제라고 하셨는데요. 왜 성능상의 문제가 생기는지 궁금하고 PK를 저렇게 굳이 묶어서 써야하는 이유가 궁금합니다.
- 미해결데이터베이스 중급(Modeling)
식별관계 관련
안녕하세요~ 식별 관계 관련해서 질문 있습니다 부모 테이블에서 자식테이블로 식별/비식별 관계로 상속 할때 자식테이블로 pk가 아닌 일반 속성으로 fk를 설정한다고하면 부모없이 자식이 있을 경우에 일반속성으로 상속한다고 생각하면 될까요? 모델링 할때 어떤 경우에 식별로 설정해야 할지(pk로) or 비식별(일반속성) 으로 구분해야 하는지 알고 싶습니다.
- 미해결데이터베이스 중급(Modeling)
이력 관리 테이블 설계에 대해 질문드립니다
안녕하세요 강사님 강의 정말 잘 듣고 있습니다 제가 고민을 해봐도 해결되지 않는 내용이 있어서 질문을 드립니다 제가 유저 개인정보 변경 이력 테이블을 만들려고 하는데요 유저 개인정보는 관리자가 관리자 페이지를 통해서 변경할 수도 있고 사용자가 직접 마이 페이지를 통해 변경할 수도 있습니다 예를 들어 바뀔 수 있는 항목 3개라 치고 A, B, C라고 칭한다면 (항목은 이메일, 담당자 이름, 근무지, 근무 상태 같은 것들입니다) 변경 전 before A, before B, before C 변경 후 after A, after B, after C 변경일자 xxxx.xx.xx 개인정보가 변경 될 때마다 데이터가 쌓여, 변경일자 내림차순으로 화면에 보여지는 방식입니다 A만 변경했다고 하더라도 A, B, C는 전부 표기되어야 합니다 1. 이력 관리는 1개의 테이블에 같이 저장하면서 대신 컬럼 하나 추가해서 개인정보를 관리자가 변경했으면 1, 사용자가 변경했으면 2 이런 식으로 플래그를 주려고 합니다 이러한 방식으로 설계하는 게 맞다고 생각은 되는데 혹시 요구사항에 따라서 2개의 테이블(관리자가 이력 관리한 테이블, 사용자가 이력 관리한 테이블)로 분리해서 각각 저장하는 방식으로 설계하는 경우도 있을지 궁금합니다 2. 만약에 화면에 보여지는 그대로 before, after, 변경일자 테이블 컬럼을 생성한다면 설계는 쉽겠지만 추후 변경할 수 있는 개인정보 항목이 더 늘어날 걸 생각하면 확장성이 좋지 못하고 또 1개 항목만 바꾸고 저장했을 때도 전부 다 DB에 저장하는 거는 더미 데이터가 많이 쌓여서 좋지 못할 것 같습니다 이력 관리 테이블 설계에 대해서 혹시 조언해주실 수 있는 점이 있으실까요?
- 미해결데이터베이스 중급(Modeling)
49 분 대체키를 이용한 select
안녕하세요. 수업 듣는중 궁금한점이 생겼습니다. 대체키 혹은 PK는 의미를 가지지 않는다고 하셨는데요, 49분즈음 설명을 fk가 아닌 대체키를 이용해 select를하면 일일이 fk로 조건을 걸 필요가 없다고 하셨잖아요. 그런데 제가 원하는 정보를 가지고 있는 row의 대체키를 어떻게 찾는거죠?? 학생의 id 와 과목의 id는 각각의 이름을 통해 찾는다고 쳐도 대체키는 못찾을것 같은데요..
- 미해결데이터베이스 중급(Modeling)
책구분과 기본목록의 관계에 대해서
안녕하세요 선생님, 좋은강의 감사드립니다. 기본목록과 책구분의 관계 매핑을 1:M으로 하셨는데요그 부분이 이해가 안가서 질문드립니다. 만화를 예를들경우 책과 기본목록이 1:1이니까만화의 기본목록은 단 하나의 책구분(만화)을 가져야 하니까1:1이 되어야 하는거 아닌가요? 만화가 잡지나 소설이 될 수는없으니까요 제가 관계에대한 이해가 많이 부족한거같습니다.. 자꾸 헷갈리네요 답변 부탁드리겠습니다.
- 미해결데이터베이스 중급(Modeling)
1:1관계 질문드립니다.
안녕하세요 선생님 좋은강의 정말 감사드립니다.복습하면서 강의노트 정리하다가 질문드립니다. 1. 첫번째 질문은 1:1관계라고 정의 할수 있는 경우는 A와 B가 1:1관계에있다고 할때A테이블의 PK를 B테이블의 PK에 매핑하고그 B테이블의 PK는 FK로서도 작동하는 상태를 1:1 관계라고 정의 할수 있는건가요? 바꿔말하면 1:1관계는 반드시 두 테이블간의 PK간의 매핑이 있어야한다로 이해하면 될까요? 2. 두번째 질문은 1:1관계에서 두테이블을 매핑시 FK를 어디에 두는게 좋은지에 대한 질문입니다.강의 내용에 나온 공통정보와 세부정보의 1:1관계의 경우공통정보쪽이 주도권을 가지니까 공통정보쪽에 FK를 두는게 맞는걸까요?
- 미해결데이터베이스 중급(Modeling)
1:1 관계에 질문이 있습니다.
부모 테이블에 자식 테이블 명을 넣으면 된다는 말이 이해가 되지 않습니다. 처음에 이렇게 생각했습니다. 부모 테이블의 PK를 자식 테이블의 PK와 동일하게 맞춰라 그러면 PK 없이 각 테이블의 연관성 있는 데이터를 동일한 PK로 가져올 수 있다. 헌데 과연 이게 적절한지 궁금합니다. 관련이 있는 테이블이라면 정확성과 신뢰성을 위해 부모 테이블에 자식 테이블의 PK가 있어야 하는게 아닌가? 그리고 자식 테이블의 PK가 있다면, PK 값은 중요하지 않지 않을까? 해당 PK만 참고하면 직관적으로 해당 테이블의 PK 위치를 참고하면 되니깐, 1:1 무결성에 의해 부모가 삭제되면 연관된 자식 테이블의 데이터도 삭제되도록 "on delete cascade"를 설정하면 되는거 아닌지요? 혹 말씀하신 내용이 Table 내 데이터 크기를 최적화 하기 위한 것인지 알고 싶습니다 강의 중 언급하신 내용이 이해하기가 조금 어려워 질문을 드립니다.
- 미해결데이터베이스 중급(Modeling)
PK 선정하기
지금 개발중인 웹사이트 url의 보안을 위해 pk에 uuid를 적용하여 사용하고있는데요, 성능상 손해를 보기때문에 이를 바꾸고자 합니다. URI 보안과 성능 둘다 잡을 키 설정 방법이 있을까요??
- 미해결데이터베이스 중급(Modeling)
안녕하세요!
- 학습 관련 질문을 남겨주세요. 상세히 작성하면 더 좋아요! - 먼저 유사한 질문이 있었는지 검색해보세요. - 서로 예의를 지키며 존중하는 문화를 만들어가요. - 잠깐! 인프런 서비스 운영 관련 문의는 1:1 문의하기를 이용해주세 교수님. 강의 감사히 잘 듣고 있습니다 혹시 , 일대일로 개인 과외는 어려우실까해서요 40살된 늦깍이 학생인데, 교수님께 배울수 있는 방법이 있을까요
- 미해결데이터베이스 중급(Modeling)
일대일 관계와 테이블명 칼럼에 대한 질문입니다.
안녕하세요. 일대일 관계를 적용해서 기본목록과 나머지 세부 정보들을 분리해서 처리할 수 있다는 것, 그리고 테이블명을 기본목록 테이블에 보관함으로써 모든 테이블을 다 뒤지지 않더라도 관련 테이블을 빠르게 찾아서 조회해볼 수 있다는 것이 중요한 것 같은데요. 혹시 테이블명의 경우는 별도의 기준 테이블을 만들어서 목록들을 관리해야하는 것이 아닌가 하는 생각이 드는데, 그렇게 하는 것이 나을까요? 아니면 예시에서 굳이 그렇게 하시지 않은 이유가 있나요? 그리고 테이블명을 등록해두고 조회할 때 가져오는 경우 쿼리는 어떤 식으로 작성하나요? 하나의 쿼리문으로 처리하는 게 아니라 앱에서 db에 접속해서 정보를 가져올 때 테이블명을 일단 먼저 가져오고 다음 쿼리에서 그 테이블명을 이용해서 정보를 불러오는 상황을 가정한 것인가요? 좋은 강의 감사합니다.
- 미해결데이터베이스 중급(Modeling)
Primary Key 선정 기준
안녕하세요, 강의 잘 듣고 있습니다 Primary Key 지정할 때 Unique와 Not Null 두가지가 중요하다고 말씀해 주셨는데요 1. 레코드 최대 수가 int 형 범위 이내이면 굳이 Primary Key 선정에 대해 고민을 안하고 모든 테이블 Primary Key를 id (int형 자동증가)로 설정해도 되나요? 2. 실무에서 id(int 형 자동증가) 로 쓰는 경우가 많은 가요? 3. 수강신청시스템의 경우 학번으로 primary key 지정 vs id(int형 자동증가) 지정 어떤 장단점이 있는지 궁금합니다. 감사합니다!
- 미해결데이터베이스 중급(Modeling)
선생님 질문있습니다
지금 mysql로 따라가고 있는데요 Openlecture에서 Seq 컬럼에 대해서 OpenLectureSeq을 fk로 설정하려고 할때 에러가 떠서 확인해보니까 Seq 컬럼이 pk가 아니라서 참조가 안되는거 같습니다. 이럴때는 Seq을 그냥 pk로 설정하고 OpenLectureSeq을 이어줘서 fk로 설정해야 하나요?
- 미해결데이터베이스 중급(Modeling)
2정규화 질문드립니다
안녕하세요 2정규화 질문드립니다 리그소분류명을 2정규형 위반이라고 본다면(18:20) 위 강의 내용에서 질문이 있습니다 리그대분류와 리그소분류는 1:M 의 관계라고 생각되는데 이 경우 나올 수 있는 관계는 식별관계, 비식별관계 두가지라고 생각됩니다 하지만 해당 부분의 강의를 보면 리그분류라는 테이블이 나오는데 이것은 앞에서 배운 것처럼 리그대분류, 리그소분류 두 테이블의 관계가 M:N 이라고 할때 비지니스 테이블로 나와야하는 테이블로 보입니다 그래서 리그분류 테이블이 나온 이유가 잘 이해가 되지 않습니다 중복을 허용하지 않겠다는 의미로 사용한다고 해도 1:M(식별관계, 비식별관계) 로 가능하기때문에 의미가 없어보입니다 2정규형 위반이라 할지라도 1:M, M:N 의 관계를 고려했을때 리그분류는 도출되지 않아야 할 테이블 아닐까 생각되는데 아직 모델링이 익숙치 않아서 잘 모르겠습니다
- 미해결데이터베이스 중급(Modeling)
Subject 테이블과 Lecture 테이블 질문드립니다.
요구사항에서 과목은 학년별로 담당선생님이 따로 있다. "과목은 '학년별로'" 이 부분에서, 강의에서는 Subject를 마스터 테이블로 만들고, OpenLecture 관계 테이블에 GradeId 를 외래키로 썼더라구요. 혹시 이 부분에서 Grade를 OpenLecture 테이블이 아닌 Subject 테이블의 외래키로 설정하고, SubjectId 랑 GradeId를 묶어서 PK로 선언하고 Subject 테이블의 PK를(GradeId, SubjectId) OpenLecture 테이블의 외래키로 설정해도 상관 없을까요? 컬럼 수로만 따지면 변경사항은 없으나 관계 매핑에서 차이가 좀 있더라구요. 항상 좋은 강의 감사드립니다.
- 미해결데이터베이스 중급(Modeling)
M : N 관계 질문드립니다.
안녕하세요. 최근에 강의를 사서 매우 만족하며 듣고 있습니다. 들으면서 궁금한 점이 있어서 질문좀 드립니다. 예를 들어 학년과 반 테이블이 있다면, 제가 SpringJPA 를 공부하면서 배우기로는 한 학년에 여러 반이 존재하고, 한 반은 여러 학년에 존재할 수 있으므로 서로 1 : N 관계인 M : N 관계가 형성이 되는데요. 근데 이 강의를 접하고 나서는 굳이 중간 테이블을 하나 만들면서까지 M : N 관계를 고집하지 않아도 될 것 같더라구요. 예를들어 한 학년에는 여러 반이 존재하니, 학년 테이블과 반 테이블을 1 : N 관계로 설정 하고, 이번 강좌에서 한 것처럼 반 테이블에 외래키인 학년 ID 랑 반 ID를 같이 묶어서 PK로 만들면 PK가 중복될 일 없이 M : N 테이블 관계를 만든 것 처럼 역할을 할 수 있는것 같더라구요. 그래서 여기서부터 의문이 들었습니다. 실전에서는 M : N 관계라도 비즈니스 관계가 (예를 들면 이번 강의에서 "선생님" 이 "과목" 을 "개강하다." 처럼) 있는 것이 아니면 위에서 말한 학년 반 처럼 1 : N 으로 만들고 N 테이블 쪽에는 PK 를 묶어서 정의하나요? 그리고 이번 강의에서처럼 강사님처럼 "선생님" 이 "과목"을 "개강하다" 라는 문맥을 만들어서 비즈니스 관계를 찾는게 아직은 익숙하지가 않더라구요. 혹시 요구사항문을 보고 이런 것을 빨리 캐치하는 팁 같은것은 없을까요? 당연히 반복된 연습이 제일 최고인 것은 알지만 혹시나 싶어서 질문드려봅니다. 좋은 강의를 정말 좋은 가격에 만들어주셔서 너무 감사드립니다.
- 미해결데이터베이스 중급(Modeling)
32분 질문 있습니다.
조인을 했을 때 1학년 1반, 3학년 1반을 보여주잖아요. 근데 학년 테이블의 PK인 학년 번호를 반드시 포함해서 프로그래머한테 넘겨줘야 한다고 하셨는데, 자식 테이블의 PK는 안 넘겨줘도 상관없나요? 아니면 반 테이블의 PK인 학년 번호와 반 번호도 같이 넘겨주는 것이 이상적인가요?
- 미해결데이터베이스 중급(Modeling)
1:M 재귀 관계에 대한 질문입니다.
안녕하세요. SQL 강의를 다 듣고 DB 모델링 강의로 넘어와서 잘 듣고 있습니다. 데이터베이스의 관계들에 대해서는 대략적으로만 알고 있었는데 재귀관계를 이용해서 나타낼 수 있다는 점은 꽤 흥미로웠습니다. 저 그런데 실무에서는 언제 1:M 재귀 관계를 사용하게 되는지 알 수 있을까요? 한 테이블 안에서 여러 단계의 1:M 관계를 나타낼 수 있는 경우에 구체적으로 어떤 이점이 있나요?