묻고 답해요
164만명의 커뮤니티!! 함께 토론해봐요.
인프런 TOP Writers
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
물리적으로 외래 키 제약 조건을 설정하지 않을 때
안녕하세요, 이번 강의를 듣고 아주 간단한 질문을 남깁니다.Soft Delete + 이력 테이블 설계가 필요한 이유가 외래 키 제약 조건으로 인한 삭제 어려움 때문이라 이해했습니다.일부 실무자들은 이러한 삭제 불편함으로 인해 물리적으로 외래 키 제약조건을 DB에 걸지 않는다는 말을 들은 적이 있는 것 같은데요, 만약 그렇게 제약이 없다면 단순히 Hard Delete + 이력 테이블 구조로 고정해도 괜찮은 걸까요?
-
미해결멀티패러다임 프로그래밍 1편: 반복자 패턴 & LISP (with TypeScript, Clojure, Kotlin)
예제 소스코드 실행 관련 문의
윈도우10 환경에서 테스트 중입니다.파일을 다운로드 받아서 PowerShell에서 패키지를 설치하고 명령어를 실행했지만, rune Server 관련 에러가 나오는데, 무엇이 문제인 걸까요? PS C:\dev\study\multi-paradigm-programming-main> pnpm -F lecture dev> lecture@1.0.0 dev C:\dev\study\multi-paradigm-programming-main\apps\lecture> pnpm rune dev▲ Rune Server v1.0.24⨯ Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only URLs with a scheme in: file, data, and node are supported by the default ESM loader. On Windows, absolute paths must be valid file:// URLs. Received protocol 'c:'at throwIfUnsupportedURLScheme (node:internal/modules/esm/load:187:11)at defaultLoad (node:internal/modules/esm/load:82:3)at ModuleLoader.load (node:internal/modules/esm/loader:815:12)at ModuleLoader.loadAndTranslate (node:internal/modules/esm/loader:594:31)at #createModuleJob (node:internal/modules/esm/loader:624:36)at #getJobFromResolveResult (node:internal/modules/esm/loader:343:34)at ModuleLoader.getModuleJobForImport (node:internal/modules/esm/loader:311:41)at process.processTicksAndRejections (node:internal/process/task_queues:105:5)at async onImport.tracePromise.__proto__ (node:internal/modules/esm/loader:664:25) {code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'}
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
`전체 행 스냅샷 이력 테이블`의 대상 테이블 칼럼 변경
안녕하세요.주문, 상품과 같은 비즈니스에 중요한 데이터를 전체 행 스냅샷 이력 테이블로 관리 하는 상황일 때, 대상 테이블(주문, 상품 등)의 칼럼이 추가/삭제되는 상황에 이력 테이블에 어떻게 반영해야할지 질문 드리고 싶습니다.- 추가: 신규 기능으로 인해 새로운 칼럼 추가- 삭제: 기획 변경으로 오랜 기간 미사용 칼럼으로 낭비되어 삭제로 결정된 경우 등
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
common_code_detail의 code 변경 가능성
안녕하세요 영한님. 강의 정말 잘 듣고 있습니다.common_code_detail은 pk로 natural key(group_code, code) 를 사용하는 것이 정형화되어 있다고 하신 부분을 이해했습니다. 서비스를 운영하다 보면 code의 값을 수정할 경우가 생길 가능성이 있을 거 같은데요.예를 들면, 다음과 같은 요구사항이 있을 거 같습니다.group_code가 ORDER_STATUS 인 code에 대한 변경 요청.SHIPPING 을 두가지 상태로 확장(SHIPPING_START, SHIPPING_COMPLETED)변경 전의 SHIPPING은 SHIPPING_COMPLETED로 취급한다. 설계 1편의 "pk는 immutable해야한다" 라는 3번째 규칙이 있었는데요.공통 코드 테이블의 경우에는 3번째 규칙을 유연하게 적용해야하나? 하는 생각이 들었습니다.공통 테이블은 natural key를 사용하니 어느정도 허용을 한다고 보면 될까요?아니면, 기존 키는 삭제하지 않은 채로 그대로 두고 새로 만들어서 규칙을 지키는 방향으로 하시는지 궁금하네요. 실무에서 이런 케이스들은 어떻게 다루시는지 궁금합니다. 감사합니다.
-
해결됨김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
수업자료 pdf파일관련 건의 - 제목 링크위치 개선
이번 강의의 수업자료 pdf 보니, 제목 클릭 시 링크위치가 각 챕터가 아닌, 마지막 페이지 정리 내 제목들로 이동합니다.9. 논리적 모델링 - 실습.pdf 파일 제외하곤 모든 파일의 목차들이 다 마지막 정리로 이동하더라고요.그동안 영한님 강의들 자료에는 각 챕터로 쉽게 이동 하기 좋았거든요. 이부분이 개선 가능할까요?이 상태여도 학습은 가능한데, 건의드립니다. 감사합니다.
-
해결됨제대로 배우는 Express.js: Part2 엔진 내부 동작 원리와 클론 프로젝트
학습 방향성
안녕하세요 강의를 듣다가 전반적인 학습 방향성에 고민이 있어서 질문드립니다. 풀스택 개발자가 목표입니다 취업전 총 3번의 프로젝트를 진행 해보려고 합니다.(실서비스 프로젝트 1개 / 실서비스 프로젝트를 위한 연습 프로젝트 2개 ) 첫번째 프로젝트는프레임워크를 사용하기 전 전반적인 기초체력을 기르기 위해서fe - 바닐라 js로 spa방식 (csr)be express로 api구성 + 로우쿼리로 db 연동 두번째 프로젝트는 추후 next, nest 등 프레임워크 학습후 진행 해보려고 합니다.fe - nextbe - nest + prisma 등인프라 - aws운영 - • Sentry - 에러 추적 • CloudWatch - AWS 로그/모니터링 • Datadog - 통합 모니터링 • Winston / Pino - 로그 라이브러리 실서비스 프로젝트는 fe는 next / be는 nest를 사용해 개발할 예정이고실제 사용자가 있는 b2b 쇼핑몰이라 배포/인프라(aws), 운영(모니터링/로깅)까지 a~z까지 모두 경험 해볼 프로젝트입니다. 현재 첫번째 프로젝트를 위해강의자분께서 제공한express part1 수강은 끝난 상태입니다프론트 및 db관련 강의들은 타 강의자분의 강의를 통해 준비를 마친 상태입니다. 혹시 part2 까지 수강후전반적인 기능구현 실습들을 진행 해보는 타강의를 수강하고 프로젝트를 시작해야할까요아님 프로젝트 경험 먼저 해본뒤 part2 강의수강, 기능구현 실습강의를 수강 하는게 더 효율적일까요.. 프로젝트 완성도를 위해 강의만 쭉 들으니어디까지 공부를 해야하는것인가에 대한 기준도 안 잡히고강의만 듣고 직접 강의 코드를 쳐보는것만으로는 구현력이 안 길러지는 것 같습니다..또한 강의 수강 기간이 길어지다보니앞서 들었던 강의 내용들이 잘 기억이 안 나는 부분들에 대한 걱정 또한 있습니다.반면에 실무적인 코드 경험 (강의를 통한 간접경험) 없이 프로젝트를 진행하면실무에서 쓰지 않는 코드 / 리펙토링 하기 어려운 코드 / 보안에 대한 인식 부재로 인한 위험성 등여러가지 잘못된 코드를 작성하고 학습하게될까봐 두려움이 있습니다. 어느 시점에 구현력을 기르기 위해서 프로젝트를 진행 해봐야하는지도무지 감이 안 잡혀서 질문 드립니다.. 강의 외적인 성격이 짙은 질문인데 염치 불구하고 질문드립니다..
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
[해결책 - 코드값 분리] 중 orders(order_status) - common_code(code) 타입 불일치 제보
안녕하세요 첨부된 sql 파일 [-- ### 해결책 - 코드값 분리] 에서 orders 테이블 order_status의 타입이 common_code의 code 타입과 동일하게 VARCHAR(50)으로 변경되어야 할 거 같습니다. -- ### 해결책 - 코드값 분리 CREATE TABLE orders ( order_id BIGINT PRIMARY KEY AUTO_INCREMENT, member_id BIGINT NOT NULL, order_status VARCHAR(20) NOT NULL, total_amount INT NOT NULL, created_at DATETIME NOT NULL ); CREATE TABLE common_code ( code VARCHAR(50) PRIMARY KEY, name VARCHAR(100) NOT NULL );
-
미해결AI 시대 대체되지 않는 미국 빅테크 시스템 디자인 & 오픈소스 실무 기여 완성 코스
유튜브 예제에서 흐름 관련 질문있습니다
유튜브 예제에서 사용자가 동영상을 요청하면 CNAME으로 CDN에 먼저 가는 것이 아니라 API 게이트웨이로 갔다가 CDN으로 요청을 보내는건가요?
-
해결됨김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
서비스 운영 중 잘못된 테이블 설계 발견시 수정 시점에 대한 질문
안녕하세요 영한님! 기초부터 설계까지 영한님의 강의 덕분에 실무에서 테이블을 설계할 때 큰 자신감을 얻고 있습니다. 늘 감사드립니다.강의를 듣고 운영 중인 서비스의 ERD를 검토해보니 과거 설계된 테이블들이 비식별 관계가 아닌 식별 관계로 되어 있는 등 개선이 필요한 상황입니다. 하지만 1인 개발 상황에서 데이터 마이그레이션을 수반한 대규모 리팩토링은 리스크가 크고, 기획팀의 신규 기능 배포 속도도 맞춰야 하는 딜레마에 빠져 있습니다.조만간 동료 개발자가 합류할 예정인데, 현시점에서 제가 취해야 할 스탠스에 대해 의견을 여쭙고 싶습니다.방안 A: 기획팀에 상황 공유후, 일괄 재설계를 통해 '기술 부채'를 완전히 청산하고 신규 기능을 올린다.방안 B: 영향도가 큰 부분부터 점진적으로 수정하며, 팀원이 합류한 뒤 안정적으로 함께 리팩토링을 진행한다.영한님의 실무 경험에 비추어 보았을 때 어떤 결정을 내리는 것이 팀과 서비스 관점에서 더 좋을지 조언해주시면 큰 도움이 될 것 같습니다. 감사합니다.
-
해결됨김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
계층 구조 모델링 기타 방법들
안녕하세요 영한님!섹션 3의 계층 구조 강의를 듣고, 계층(트리) 구조를 모델링하는 다른 방법에 대해서도 찾아보면서인접 리스트 모델 , 폐쇠 테이블 모델 이외에도 경로 열거 모델, 중첩 세트 모델 등이 있다는 점을 알게되었는데요 실무에서 경험을 묻고싶습니다!강의에서 소개해주신 이외에도 다른 모델을 상황에 맞게 자주 사용하시는지, 혹은 다른 방법들의 단점으로 인해 결국 인접 리스트와 폐쇠 테이블 모델의 사용으로 귀결되는 것인지 궁금합니다.
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
섹션 9의 퀴즈가 영어로 출력되요.
섹션 9의 퀴즈가 영어로 출력되요.
-
해결됨김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
섹션 6 SOFT DELETE) UNIQUE 제약 조건 + 가상 컬럼
안녕하세요!질문이 있습니다Soft delete 환경에서 UNIQUE를 걸 시, 가상 컬럼을 이용한 해결 방법은 소개되지 않은 이유가 있나요?가상 컬럼으로 해결하는 방식은 추천하지 않는 방법인가요? 예를 들어,(MySQL)목표 = Member - email의 unique를 지키는 것 <Member 테이블>필드 = email, deleted_at, _active_checkUNIQUE(email, _active_check) 이때,가상 컬럼 =_active_check-> _active_check BOOLEANGENERATED ALWAYS AS (IF(deleted_at IS NULL, TRUE, NULL)) VIRTUAL; 이렇게 하면hello 계정 생성email = "hello", deleted_at = null, _active_check = true(이때, hello 계정은 다시 INSERT 불가 (UNIQUE(email, _active_check))hello 계정 soft 삭제email = "hello", deleted_at= 2025.01.01, _active_check = nullhello 계정 다시 생성 email = "hello", deleted_at= 2025.01.01, _active_check = nullemail = "hello", deleted_at = null, _active_check = true=> 결과적으로 UNIQUE 제약이 지켜짐 가상 컬럼을 활용하여, Soft Delete 환경에서 UNIQUE 제약을 지키는 방식은 좋지 않은 방법인가요?
-
미해결AI 시대 대체되지 않는 미국 빅테크 시스템 디자인 & 오픈소스 실무 기여 완성 코스
Spotify 서비스 설계에서 transcoder service에 대해 문의 드립니다.
안녕하세요. transcoder service에 대해 문의 드립니다.해당 서비스는 음악파일에 대한 변환으로 이해했는데요. 그렇다면 변환 과정을 거쳐서 file storage 로 넣어야하지 않을까 싶어요.혹시 언급된 transcoder가 다른 의미가 있을까요?
-
해결됨김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
섹션2 공통 코드) 애플리케이션 ENUM을 API에 그대로 노출한다면?
안녕하세요! 강의 정말 재밌게 보고있습니다궁금한 점이 있습니다애플리케이션 ENUM을 쓴다고 가정합니다.이때, (PENDING, 대기중)에서 PENDING만 API로 주면 안되나요? FE에서 PENDING을 보고 "대기중"으로 글씨를 띄우면 안되는 걸까요? 기획자의 요구에 따라서 "대기중"이라는 글씨의 변경 요청을 BE, FE 누가 담당하는게 맞는 건가요?
-
미해결UML과 객체지향 설계 입문: 비전공자도 쉽게 배우는 개발자 필수 기초 강의
안녕하세요. 수업 자료 링크 제공은 어디인가요?
안녕하세요. 수업 잘 듣고 있습니다.수업 자료 링크는 어디에서 볼수 있을까요?
-
미해결김영한의 실전 데이터베이스 - 설계 2편, 실무에서 반드시 마주치는 9가지 설계 패턴
NoSQL 질문있습니다.
NoSQL은 대규모 분산시스템 환경에서 CAP중에 AP을 주로 선택하는 모델이라 Eventual Consistency모델로 알고 있습니다. 하지만, NoSQL도 서버를 한대만 사용하면 Strong Consistency가 아닌가라는 생각이 들었습니다. 강의에서 설명해주신 NoSQL은 Eventual Consistency모델이다라고 하신거는 일반적인 사용환경이 대규모 분산시스템이기 때문에 Eventual Consistency라고 하신걸까요? 아니면 제가 잘못 생각하고 있는 것일까요?
-
해결됨AI 시대 대체되지 않는 미국 빅테크 시스템 디자인 & 오픈소스 실무 기여 완성 코스
특별 학습 자료 프로모션 1년 멤버십 무료 제공 지원 확인 방법
특별 학습 자료 프로모션 1년 멤버십 무료 제공 지원 어떻게 확인할 수 있을까요?
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
실무적인 설계로 접근했을 때 제 2정규형 항상 만족?
안녕하세요. 질문이 있습니다!! 제2정규화는 제 1 정규형을 만족하고, 테이블의 기본키가 복합키일 때 부분 함수 종속이 있으면 적용할 수 있잖아요 근데 이전 강의 영상에서 말씀하셨듯이 유연하고 확장성 있는 설계를 하기 위해 자연키가 아닌 대리키를 사용하고, 연관 엔티티(매핑 테이블)을 두어 사용하려면 비즈니스 로직에 따라 유니크 제약조건을 걸어 해결하라고 하셨습니다 그럼 여기서 궁금한 것이 이렇게 실무적인 접근으로 설계를 한다면(대리키) 항상 키는 단일컬럼 키니까 복합키가 아니라서 항상 제 2정규형을 만족하는 것인가요??
-
미해결AI 시대 대체되지 않는 미국 빅테크 시스템 디자인 & 오픈소스 실무 기여 완성 코스
[위치 이름 기반으로 호텔을 조회하는 메서드] 코드 질문 드립니다.
강의 마지막에 위치 이름 기반으로 호텔을 조회하는 메서드 관련하여 질문 드립니다. 참조 관계강의에서 hotel, location 양쪽에서 서로를 참조하고 있습니다. 여기서는 location에서만 hotel을 참조하는 것이 맞지 않나요?? 우선 location을 생성할 때 hotel이 필요하고, location은 호텔을 위해 생성된 호텔에 종속적인 모델이기 때문에 location에 두는게 맞다고 생각합니다. 위치 기반 호텔 조회 메서드1번에서 location에서 호텔을 참조한다면, 위치 기반 호텔 조회 메서드는 location에 있어야 한다고 생각합니다.또한 지금 호텔을 전부 탐색하며 일치하는 모델을 찾고 있는데, 그냥 단순히 bruteforce 로직을 보여주시려고 하신걸까요?? 호텔과 location을 조인해서 가져오거나, 그냥 location에서 name 인덱싱을 걸고 호텔 id 값 찾아서 + 호텔 조회하는 그런 방식을 생각했는데 logic으로 적어주신 이후 최적화 과정이 빠진 것이 아쉽습니다. 이런 부분들을 어떻게 최적화 할 수 있는지 다양한 방법들을 배우고 싶습니다ㅠ 제가 맞다고 주장하는 것이 아니라 몰라서 질문 드립니다.감사합니다 :)
-
미해결김영한의 실전 데이터베이스 - 설계 1편, 현대적 데이터 모델링 완전 정복
슈퍼/서브 타입 joined 전략
db의 슈퍼/서브 타입으로 설계된 부분을 보면 joined 전략으로 했을 경우 어쩔 수 없이 식별 관계로 해야하는 경우가 있던데 이럴 경우 sigle table 전략으로 푸는 게 나은 것 같으세요? 아니면 어쩔 수 없이 식별 관계로 풀려고 하는 게 나은 것 같으신가요?