어제 2유형 이론을 한번 들어봤는데(분류까지) 생각보다 내용이 많고 뭔가 정리가 안되는 듯 해서 제가 좀 코드를 축약하는 방식으로 나름 2유형을 정리해봤습니다. 코드가 괜찮다면 제가 적은 것을 암기해서 2유형은 문제 풀이로 마무리 할까도 살짝 고민이 되요. 저걸로 2유형 충분히 대비가 될찌 궁금하며 어떤식으로 준비하면 될지 시간 되시면 답변 부탁합니다.
작년 개인적인 사정으로 인해 그동안 준비를 못하고 있다가 이번 6/20 실기 시험에 도전하게 됐습니다... 혹시나 수강 기간 연장이 가능할까 싶어 문의드립니다. 추가요금이 필요하다면 지불한 의향도 있습니다. 제 메일 주소는 ejrgns0506@gmail.com 입니다. 감사합니다,
안녕하세요! 이번에 빅분기 실기 대비로 선생님 교재와 인강 모두 사용해서 공부중에 데이터 관련하여 문의 드립니다. health_survey2.csv가 있어야 lifestyle 관련 분석이 가능할것같은데 현재 책에 적힌 깃허브에는 health_survey1.csv밖에 없는것같습니다.
안녕하세요. 작년 11회 시험에서 5점차이로 아쉽게 떨어지고 다가오는 6월 20일 실기시험을 다시 준비하고 있습니다. 현재 수강기간이 일주일도 남지 않은 상황인데 혹시 수강기간 연장 또는 부분결제 가능여부에 대해서 정중히 문의 드립니다. 제 메일 주소는 hyoki97@naver.com 입니다. 항상 건강하시고 좋은 하루보내세요 감사합니다.
안녕하세요, 유저 테이블과 구독 테이블 설계 중 해결하기 까다로운 지점이 생겨 질문드립니다. *현재 상황을 보다 이해하시는데 문제가 없으시기 위해 ai로 질문을 정리한점 먼저 말씀드립니다. 1. 현재 상황 및 서비스 정책 유저 테이블: id(PK) , email(UK) / 탈퇴 시 소프트 삭제, 개인정보 보호를 위해 이메일 마스킹 필수. 구독 테이블: 현재 활성화된 구독 정보 딱 1건만 관리 (이력은 별도 테이블 존재). 서비스 정책: 탈퇴 후 동일 이메일로 재가입 시, 기존 로우 복구가 아니라 새로운 로우로 Insert 됩니다. 단, 재가입 시 과거 구독 정보는 그대로 이어받아야 합니다. 2. 제가 고민해 본 방법들과 예상되는 문제점 생각한 방법 1) 구독 테이블이 유저 PK( id )를 외래키로 바라보게 한다. 예상 문제: 재가입 시 유저 테이블에 새 로우가 Insert 되면서 새로운 PK를 발급받기 때문에, 과거 PK를 바라보고 있던 구독 테이블과 연결 고리가 끊어집니다. 생각한 방법 2) 유저 테이블에 '이메일 해시(유니크X)'를 두고, 구독 테이블과 해시값으로 매핑한다. 예상 문제: 해시는 개인정보가 아니므로 탈퇴 후에도 유저 테이블에 남겨둘 수 있어 재가입 매칭은 가능합니다. 하지만 유저가 중간에 이메일을 변경하는 경우 , 유저 테이블의 이메일 해시뿐만 아니라 구독 테이블 및 구독 이력 테이블의 해시값까지 전부 동시 UPDATE 쳐야 하는 번거로움이 생깁니다. 3. 질문 요약 개인정보 보호를 위해 유저 테이블의 이메일 원본은 마스킹하면서도, 재가입 시 동일인임을 식별해 과거 구독 정보를 매칭해 주어야 합니다. 여기에 유저의 이메일 변경 가능성까지 고려해야 하는 상황입니다. 이 경우 구독 테이블의 매핑 키 체계를 어떻게 잡는 것이 가장 깔끔하고 현명한 DB 설계 원칙 일까요? 실무에서 이런 케이스를 해결하는 정석적인 아키텍처 가이드가 궁금합니다!
자연키vs대리키 강의를 보면 대리키를 사용하는게 안정성,유연성에 있어 많은 장점이 있어 대부분 대리키를 사용한다고 하셨는대, 다음과 같은 케이스에도 대리키를 쓰는게 좋을지 궁금합니다. (뒤에 강의에 나올수도 있지만 현시점 궁금해서 질문드립니다.) 1. 조인테이블의 경우 a,b테이블의 pk인 대리키를 이용해 복합키를 만들어서 pk로 쓰면 될지, 아니면 그것 역시 따로 대리키를 만들어야 할지 궁금합니다. 2. 정말 단순한 enum 형태의 테이블일 경우, 예를 들어 유저상태값을 표현하기위해 정상,휴면,탈퇴 등을 기록하는 테이블의 경우 자연키, 대리키 어떤거를 써야할지 궁금합니다. 제가 경험한 바로는 enum 형태의 간단한 테이블조차 대리키를 사용하니 유저 테이블을 조회할때 간단한 상태값조차 조인을 해서 봐야하니 불편하더라고요. 감사합니다.
공식 문서 보고 공부를 해도 될 공부를 비싼 돈내고 강의를 듣는거는 질문이나 대응을 기대하고 관리를 해줄거란 생각에 지불하는 것인데 이렇게 관리를 안하고 방치를 할거면 양심상 강의를 내려야 할거 아닌가요? 어떤 생각으로 강의를 내 놓았는지 몰라도 내가 누군가를 가르친다 생각한다면 그만큼 책임감도 함께 가져갸아 한다 생각하는데 이 분은 제 피땀으로 번 돈으로 들은 강의가 너무 아깝다고 만들어준 강사로 기억에 남게 될것 같습니다......... 강의 내용도 제 기준으로 너무 부족해 그냥 클로드한테 물어보러 왔다 갔다 할랍니다....
실기 공부를 5월 25일부터 시작하려고 하는데 질문 글들 보니까 개정이 된다는 식으로 나오더라구요? 그럼 기존 학습 자료들이 모두 바뀌는 건가요? 26년 1회 기출은 아직 공부 안 했으니까 상관없고 앞으로 어떻게 되는지? 정확한 일자가 어떻게 되는지 알고싶어요. 기존 자료를 출력해서 공부하면 될까요?
'f5' 칼럼이 0이 아닌 데이터(행)를 구하시오 -> 0이 아닌 칼럼을 제거하라는 말은 아니었다고 판단했는데요, (그래서 아래 코드로 0이 아닌 칼럼의 수를 구했습니다.) cond = df['f5'] !=0 sum(cond) 문제는 이해할 수 있으나, 향후 이렇게 문제 해석 상의 판단에 따라 정답이 달라지는 경우가 자주 발생할까요?
강의를 수강하시다가 막히는 부분이 있는 경우는 "자주 묻는 질문"을 먼저 참고 부탁드립니다. 막히는 부분에 대해서 질문을 주실 때에는 꼭 강의 제목과 타임라인도 같이 작성 부탁드립니다. 안녕하세요, 강의 앞부분 수강 중이기는 하지만, 문득 중요한 문제일 것 같다는 생각이 들어서, 주식 매매 수수료에 관해 질문드립니다. 개인마다 주식계좌개설 시기에 따라 주식 매매 수수료와 환전 혜택이 제각각인 것으로 알고 있습니다. 제 한투 미국 주식 거래의 경우 한국투자증권에 문의해보니, 이번에 한투앱을 통한 뱅키스 계좌 개설시, 미국 주식 거래의 협의수수료나 이벤트 적용이 어려워, 기본 온라인 매매수수료 0.25%, 환전 스프레드 우대율이 60% 로 적용이 되어 수수료가 높은 편인데, 이 경우에도 자동매매 베개투자법을 적용해도 괜찮을까요? 그리고, 자동매매 베개투자법을 적용할 경우 판단하시는 최소 적정 계좌 예치금이 어느 정도 되실까요?
안녕하세요! 페이징 처리 방식에 대해 궁금한 점이 있어 질문드립니다. 코드를 보니 요청값으로 offset과 limit을 받고 이를 Pageable로 변환하고 있습니다. data class OffsetLimit( val offset: Int, val limit: Int, ) { fun toPageable(): Pageable { return PageRequest.of(offset / limit, limit) } } 그런데 이 방식은 offset이 limit의 배수가 아닌 경우 의도하는 바와 다르게 동작할 수 있을 거 같다는 생각이 들었습니다. 예를 들어 offset=15, limit=10인 경우 15번째 데이터부터 10개인 15~19번째 데이터를 조회하는 것이 자연스럽다고 생각했습니다. 그런데 현재 구현에서는 offset/limit 계산으로 인해 PageRequest.of(1,10)이 되고 결과적으로 10~19번째 데이터가 조회될 거 같습니다. 제가 이해한 내용이 맞을까요?? 그렇다면 이 방식은 더보기나 무한 스크롤처럼 offset이 항상 limit의 배수로 증가한다는 제약이 있을 때만 안전하게 사용할 수 있는 방식인지 궁금합니다. 예를 들어 클라이언트가 항상 아래처럼 요청한다고 정해져 있다면 문제가 없다고 봐도 될까요? offset=0, limit=20 offset=20, limit=20 offset=40, limit=20 또 이런 제약이 있다면 limit을 request로 받기보다 서버에서 고정값으로 관리하는 것이 더 나은지도 궁금합니다. 마지막으로 어떤 API에서는 offset,limit을 받고 또 어떤 API에서는 page,size를 받는 경우가 있는데 실무에서는 각각 어떤 기준으로 선택하는지도 알고 싶습니다. 취준 준비하면서 제미니님의 강의 도움 많이 받고 있습니다!! 감사합니다 ^^ <정리> PageRequest.of(offset/limit,limit) 방식은 offset이 limit의 배수일 때만 안전한 방식인가요? 더보기/ 무한 스크롤에서는 offset,limit을 사용하는 게 더 자연스러운가요?? limit이 정책적으로 정해져 있다면 request로 받지 않고 서버에서 고정하는 게 더 좋을까요? offset/limit 방식과 page/size 방식은 어떤 기준으로 선택하면 좋을까요??