안녕하세요~ 강의 수강중 통계정보 갱신에 대해 여쭤보고싶은게 있습니다. 운영중에 간혹가다 옵티마이저가 실행계획을 잘못 선택해서 쿼리를 실행해서 슬로우 쿼리가 발생되는 경우가 종종있었습니다. 이때 use index 를 사용해서 주로 해결했었는데 이번 강의에서는 문제가 되는 테이블의 통계정보를 갱신하면 이런 문제들이 해결된다고 하시던데 운영중인 db 에 통계정보 갱신을 했을때 트레이드 오프같은게 없을까요? 실무에서 보통 어떻게 하셨는지 궁금하네요.
안녕하세요! PK 설계와 관련하여 궁금한 점이 있어 질문드립니다. 강의에서는 AUTO_INCREMENT 를 사용하면 PK가 순차적으로 증가하기 때문에 랜덤한 위치에 데이터가 삽입되는 것을 줄이고, 페이지 분할을 최소화할 수 있어 사용을 권장한다고 이해했습니다. 그런데 한편으로는 MSA 환경에서 PK로 UUID를 많이 사용한다는 이야기를 들었습니다. UUID를 사용하면 각 서비스에서 ID를 독립적으로 생성할 수 있다는 장점이 있다고 하는데, 서비스별로 데이터베이스와 테이블이 분리되어 있다면 각 테이블의 PK는 해당 테이블 내에서만 유일하면 되기 때문에 AUTO_INCREMENT 를 사용해도 문제가 없지 않을까 생각했습니다. 그래서 다음 내용이 궁금합니다. 실제 MSA 환경에서는 일반적으로 PK로 UUID를 많이 사용하는지 UUID 사용으로 인한 인덱스 크기 증가와 페이지 분할 등의 단점보다 UUID의 장점이 더 커지는 판단 기준은 무엇인지 찾아보니까 시간 순서 특성이 있는 UUID v7 라는 것도 있는데 이를 사용하는 건지 이런 궁금증이 생기는데 시원하게 해결이 되지 않아서 질문으로 남깁니다. 항상 좋은 강의 올려주셔서 감사합니다. 다음 강의에 해당 내용에 대한 설명이 다 있는 것을 확인하였습니다. 감사합니다!
안녕하세요, 저는 회사에서 next.js로 포팅하여 개인적으로 좀 공부하고 있는 학생입니다. 현재 2강 할 일 관리 앱을 보면서 저희 회사의 작업 방식을 함께 생각해봤는데 저희 회사는 꼭 필요한 부분 (iron-session을 이용하여 세션을 가져온다거나)을 제외하고는 죄다 클라이언트 컴포넌트로 바꿔서 사용하고 있습니다. 그래서 이 작업을 진행하면서도 클라이언트 컴포넌트로 모두 바꾸어 진행한다면 어떨까라고 생각이 들었었는데 과제에서는 최소한의 컴포넌트만 클라이언트 컴포넌트로 바꾸라고 하신 이유가 궁금합니다. 감사합니다!
커버링 인덱스가 아니라고 가정한다면 클러스터링 인덱스까지 2번의 B+Tree 탐색을 하지만 커버링 인덱스라면 이런 탐색을 한번 줄여 발생하는 IO 작업을 최적화 하는것으로 이해 했습니다 커버링 인덱스 말고도, 자주 사용되는 페이지의 위치를 자동으로 InnoDB에서 어댑티브 해시 인덱스라는 공간에 저장 하는것으로 알고 있는데 이 방식도 IO 작업을 최적화 하는 것인지 궁금 합니다
안녕하세요. 프로젝트 재미있게 잘 보고 있는데 궁금한 내용이 생겨 문의 드립니다. mcp server 활용하라는 프롬프트 내에 기재해도 사용하지 않는 경우가 좀 있고, 실제 강사님이 쓰시는 터미널이랑 다르게 저는 tools 사용중이면 사용한다는 텍스트가 전혀 안뜨더라구요 업데이트가 되서 그런걸까요 아니면 설정을 덜 한걸까요..? 매번 양질의 강의 감사드립니다.
S C:\Users\user> irm https://claude.ai/install.ps1 | iex irm : 기본 연결이 닫혔습니다. SSL/TLS 보안 채널에 대한 트러스트 관계를 설정할 수 없습니다. 위치 줄:1 문자:1 + irm https://claude.ai/install.ps1 | iex + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : InvalidOperation: ( System.Net .HttpWebRequest:HttpWebRequest) [Invoke-RestMethod], WebExc eption + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeRestMethodCommand 이렇게 되는데 어떻게 해야 하나요?
안녕하세요, 강의 잘 듣고 있습니다. install 'cursor' command가 안떠서 install 'code' command로 설치하려는데 하기와 같은 에러가 표출됩니다. 환경변수 문제인지 확인해보았으나, path 환경 변수 지정은 잘되어 있습니다. 어떤 조치를 해야할까요?
안녕하세요 강사님 강의 잘 듣고 있습니다. 모듈형 규칙에 대해 말씀 주셨는데 궁금중이 생겨서 질문드립니다. 모듈형을 쓰는 이유는 "모듈형 규칙은 CLAUDE.md 파일이 길어지거나 특정 규칙에 대해 사용하고 싶을 때 적용한다"로 생각하면 되는데 이것을 적용할 때는 예를 들어 코드 규칙과 같은 프로젝트에 적용되는 규칙은 CLAUDE.md 파일(default)로 되어 있고 Backend 부분 API를 만들 때 /ruels/backend/api-consturction.md 처럼 만들고 해당 API 작업을 할 때 /memory로 규칙을 선택하면 될까요? 아니면 적용하지 않아도 CLAUDE.md 파일과 같이 적용되는 걸까요?
안녕하세요 영한님 마스터패스 구매하고 모든 강의를 재밌게 수강하고 있는 백엔드 개발자 취업준비생입니다. 강의를 듣다가 궁금한 점이 생겨 질문남깁니다! 답변해주시면 너무 감사하겠습니다. is_deleted 와 같은 컬럼을 사용하는 soft delete 방식은 실제 삭제 시점을 알 수 없기 때문에 주로 사용하진 않고, deleted_at을 컬럼으로 두고 삭제 여부/시점을 모두 판별할 수 있게 한다고 하셨는데, 그렇다면 뒤에 설명해주신 상태 기반 관리를 통해서 ProductStatus나 OrderStatus를 관리할 경우, deleted_at이나 다른 시점을 컬럼으로 두면 나쁜 설계라고 하셨습니다. 그렇다면 결국 ProductStatus와 같은 상태를 가진 것들은 삭제 시점이나 특정 시점을 알 수 없는건 마찬가지 아닌가요? 만약 삭제 시점이나 회원의 탈퇴 시점같은 것들을 관리해야 한다면 어떻게 해야할까요? 이러한 해결 방법으로써 이력 테이블 등의 방법이 있을 것 같은데 취준생의 개인 프로젝트로 사용하기에 규모가 너무 커지지 않을까 걱정됩니다. 실제 사례를 예시로 들어보자면 UserStatus 상태값입니다. 이를 테이블의 한 컬럼으로 두고 내부에는 ACTIVE(정상), SUSPENDED(임시정지), BANNED(영구정지), WITHDRAWN(탈퇴) 등의 여러 상태를 가집니다. 이때 만약 withdrawn_at 컬럼이 존재하지 않고 상태값만으로 관리하면 탈퇴 시점이 언제인지 등을 확인할 수 없게 됩니다. 이 경우에는 withdrawn_at 컬럼을 상태값과 함께 두는 것보다 이력 테이블을 사용하는게 더 나은 설계이자, 개인 소규모 프로젝트에서도 해당되는 사항인지 궁금합니다. 작은 조언이라도 해주시면 감사하겠습니다! -- 에이전트 인프런 에이전트에 같은 내용으로 질문을 남겨봤는데 withdrawn_at 컬럼을 상태 컬럼과 함께 사용하는 것이 효율적이고 합리적인 설계라고 합니다. 실제로 이력 테이블은 개인 프로젝트 규모정도에서는 사용하기에 관리 복잡도가 증가할 가능성이 있다고 합니다. 이에 대해 어떻게 생각하시는지도 궁금합니다.