안녕하세요. JPA 강의를 듣다가 궁금한 점이 생겨 질문드립니다. JPA 강의에서는 일대일 관계를 설명하면서 Member가 FK를 가지고 있는 방식이 더 좋다고 설명하셨고 김영한님께서도 주 테이블에 FK를 두는 방식을 더 선호한다고 말씀하신 것으로 해했습니다. 그래서 저는 일반적으로 주 테이블이 FK를 가지고 있는 방식이 더 편리하다고 생각하고 있었습니다. JPA 강의에서 해당 이미지로 설명하셨어요. 그런데 이번 강의에서는 보조 테이블이 FK를 가지고 있는 방식이 더 좋다고 설명되어서 조금 헷갈립니다. 저는 화면의 예시에서 Member가 주테이블, Locker를 보조 테이블이라고 이해했는데 강의마다 설명이 반대되는 것처럼 느껴졌습니다. 혹시 제가 잘못 이해한 부분이 있을까요?
강의들을 때는 어렴풋이 알거 같고 근데 강의듣는거 끝내고 실제로 구별해보라고 하면 잘 못하는거 같아서요. 혹시 차이점을 예를들어서 좀 쉽게 설명해주실수 있을까요? 저는 제 3 형 정규형 한거 같은데 또 보면 bcnf인거 같기도 하고 엄청 헷갈리고 있습니다. 도와주세요! 제가 찾은 건 bcnf 가 후보키가 아니라 슈퍼키라고 나와서 더 헷갈리는 거 같아요. 감사합니다. => 오랫동안 들여다 보고 이렇게 이해를 했는데 맞는지 모르겠습니다. 기본적으로 슈퍼키가 아닌 일반키가 함수결정자가 되면 bcnf 위반이 되는거고 제 3 정규형은 슈퍼키가 함수결정자이거나 일반키가 함수결정자라도 결론쪽이 후보키 중에 일부이면 (prime attribute)이면 위반이안되는거 같습니다.
안녕하세요. 수파베이스 ORM 섹션을 듣고나니 일반적인 백엔드 서버와 api 라우트를 정의하고 데이터를 주고받는게 아닌 클라이언트에서 직접 수파베이스 ORM를 호출할 수 있는 것으로 확인되는데요! 현재 회사에 프론트엔드 개발자 2명이고 백엔드 지식이 많지않아 next.js + 수파베이스로 MVP 검증부터 진행할 것같습니다. 수파베이스로 MVP 검증후 별도의 백엔드 서버로 분리하게되었을때(분리가 꼭 필요한지도 사실 잘 모르겠습니다.) 분리비용을 최소화히기위해 api호출 과정을 next.js의 api라우트를 무조건 거쳐서 수파베이스를 접근하게하려고하는데 이런 과정이 유의미한 작업이 될 수 있는지 궁금합니다.
안녕하세요. SQL 강의 중 FOREIGN KEY 정리하기 (업데이트) 파트를 듣고 있습니다. 문제는 영상시연과 달리, PDF파일의 외래키 코드를 복붙하고 번개모양 실행을 누르면 빨간 X표시가 나와요. 그 때문인지 sqlDB의 테이블스에 buyTbl ,usertbl 두개다 안떠요. 도와주시면 감사하겠습니다.
안녕하세요. 프론트엔드만하다가 강의보고 백엔드에대해 알아가는중입니다. 백엔드쪽은 아예 기반이 없다보니 하나하나 해보면서 따라가고있는중입니다. 1. 트리거는 ui로 설정을안하고 SQL 에디터로 설정을 해주셨는데 따로 이유가 있을까요?? 2. 트리거와 그 안에서 작성해주신 업데이트 함수가 별도로 관리되는것같더라고요. functions가 유틸함수고 Triggers가 시점과 적용대상(어느 테이블에 적용할지?)를 관리하는 영역으로 이해하는게 맞을까요? 3. 트리거는 테이블영역에서 적용이 불가능한가요? RSL처럼요!! 뭔가 분산되어있는 느낌이 있어서요. 4. 숙제내용 제출
안녕하세요 강사님. [실행 계획에서 type 의미 분석하기 (const, range, ref)] 강의에서 " Index Range Scan할 때 조회 범위가 크면 성능 저하의 원인이 되기도 한다. "라는 내용을 듣고 정말인지 궁금해져서 EXPLAIN을 한번 돌려봤습니다. CREATE TABLE users ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(100), age INT ); -- 높은 재귀(반복) 횟수를 허용하도록 설정 -- (아래에서 생성할 더미 데이터의 개수와 맞춰서 작성하면 된다.) SET SESSION cte_max_recursion_depth = 1000000; -- 더미 데이터 삽입 쿼리 INSERT INTO users (name, age) WITH RECURSIVE cte (n) AS ( SELECT 1 UNION ALL SELECT n + 1 FROM cte WHERE n < 1000000 -- 생성하고 싶은 더미 데이터의 개수 ) SELECT CONCAT('User', LPAD(n, 7, '0')), -- 'User' 다음에 7자리 숫자로 구성된 이름 생성 FLOOR(1 + RAND() * 1000) AS age -- 1부터 1000 사이의 난수로 나이 생성 FROM cte; CREATE INDEX idx_age ON users (age); EXPLAIN SELECT id FROM users WHERE id BETWEEN 1 AND 100000; -- type : range 결과 창에서 rows 가 100,000이 아니라 110,836으로 나오더라고요. 옵티마이저가 id 는 PK이라서 중복이 없을 거라는 것을 알고 Auto Increment가 적용되어 있어서 순차적으로 데이터가 들어갔음도 알텐데 왜 10만 개로 딱 떨어지게 예측하지 못하는지 직관적으로 잘 이해가 가지 않습니다. 감사합니다.
저는 review image reordering을 염두에 두고 sequence를 계속 가져가는 방향으로 결정했습니다. 제미니님은 실무에서 이렇게 염두에 두고 구현이 조금 더 복잡해지더라도 이런 특정 필드나 기능을 가져가는것을 오버엔지니어링이라고 생각하여 피하시는 편인가요? 어떤 기준으로 결정하시는지 궁금합니다.
image only query를 설명해주실때 stable pagination 때문에 조인을 사용하신다고 이해했습니다. 저는 다른방식으로 구현해보았는데 제미니님의 의견이 궁금합니다. 코드를 보면 나중에 image를 fetch 또 하게 되는데 이렇게되면 image only query를 ReviewImageEntity에 reviewId, status 인덱스를 걸고 SELECT review FROM ReviewEntity review WHERE review.targetType = :targetType AND review.targetId = :targetId AND review.status = :status AND EXISTS ( SELECT image.id FROM ReviewImageEntity image WHERE image.reviewId = review.id AND image.status = :status 이렇게 구현하는 방식이 데이터량이 많아진다면 효율적이지 않을까 싶어서 구현해봤습니다.
hong님 안녕하세요! 라이브 운영중인 테이블에 인덱스 추가시 고려할 사항이 궁금합니다! psotgresql이긴 하지만 금일 오전에 데이터 1800만건이 있는 테이블에 인덱스 추가를 했더니 cpu 100% 치솟는 장애 직겨탄을 맞았습니다.. (15분간 앱 사용 중단 ㅠㅠ) 뒤늦게 찾아보니 락을 잡지 않는 옵션을 추가했어야 하더군요. 새벽에 작업, 일시적인 디비 스펙업 정도만 떠오르네요. 몇천만건 ~ N억건 데이터가 있는 테이블에 인덱스 생성시 고려할 사항이 무엇들이 있는지 궁금합니다!
안녕하세요. 제미니님 유튜브 부터 인프런까지 참여하며 굉장히 많은 인사이트를 얻고있어 무한한 감사 인사를 올립니다. 질문 강의를 수강하며 제미니님이 던져준 키워드를 어떻게 곱씹어야하지? 라는 생각을 하며 두 가지 정도 질문을 드리게 되었습니다. Q1. "저같은 경우는 뭐 컴포넌트 같은 걸 좀 쪼개서 만들고 싶은데, 일단은 여러분들이 좀 혼합된 걸 느끼게 하려고 제가 풀어 놨어요" - 결제 코드 느끼기 13:17 이렇게 제미니님이 생각했던 코드를 보고 싶은데, 이 코드는 신규 강의였던 " 레거시 다루기 " 에서 개선 작업을 하나요? 아니면 저희에게 열린 사고를 던져주고 넘어가는걸까요? Q2. "success 메서드에 트랜잭셔널을 사용하는 것도 할 말이 많은데 기본적인 로직에서는 문제는 없다." - 결제 코드 느끼기 13:58 이 내용에서도 혹시 개선하는 부분도 질문 1번과 같이 레거시 다루기 강의에서 개선 하시나요? 개인적으로 success 에서 트랜잭션 어노테이션을 빼고, 저장하는 로직을 한 군데 모아서 거기 사용할 것 같은데 제미니님은 어떻게 하시는지 궁금하네요!
마지막에 professor_name을 pk로 두고 그에 따라 1:1이기때문에 과목명을 그냥 컬럼으로 두셨는데 그러면 그 과목명이 만약에 바뀐다면 (데이터베이스 -> DB) 그렇다면 데이터베이스 수업을 하는 모든 교수님의 컬럼을 바꾸어야하니 갱신이상이 일어나는것 아닌가요? 이런 경우는 어떤 정규형을 위반한건지 궁금합니다.
