대머리개발자

SELECT id, action, regDtFROM ProductWHERE action = 'EARN_TODO'AND style = 'POINT'AND regDt > DATE_SUB(CURDATE(), INTERVAL 7 DAY)AND regDt  VSSELECT id, action, regDtFROM ProductWHERE action = 'EARN_TODO'AND style = 'POINT'AND DATEDIFF(CURDATE(), regDt) = 7  EARN_TODO를 정확히 7일 후에 조건이 충족되면 EARN으로 UPDATE  해줘야 한다.따라서 UPDATE할 대상을 조회하고자 할 때 어떤 쿼리가 더 효과적인지는.. 일단 무조건 피해야할 조건은 컬럼의 함수나 연산을 좌측에 두면 안 된다. ⭐⭐인..

10년동안...사실..왜 있나 싶기도 했다.조인 대상 테이블이 하나일 때  Cross join = Inner join이 된다.실제 쿼리도  cross / inner 무엇을 쓰든 동작은 동일하다. ex)WITHscale_adj_factor AS (SELECT GREATEST(ABS(MAX(score)), ABS(MIN(score))) AS score FROM signal_history_v2)SELECT history.code , history.date , history.price , (history.score / scale_adj_factor.score) * 100 AS score , history.digital_signalFROM history_v2 AS history(cr..

MyBatis --> R2DBC로 마이그레이션 하고 있는데.. 빡치게 재미지네! 제일 험난했던 놈이다. ## 쿼리 바인딩  ## 데이터 클래스abstract class StatusDto ( val category: Int = 10, val code: String = "", val name: String = "", val price: BigDecimal = BigDecimal.ZERO, val digital: Int = 1, val movement: Int = 0)data class ScoreTimeSeries( val date:..

해당 기능이 있는 줄은... 역시 뭐든 잘 얻어 걸려야 한다. (잘 검색해야 한다.)group_concat은 row 데이터를 column 로 변경해 준다. 설문지 응답 데이터이다. 특정 사용자로 group by를 하고 응답을 하나의 Row으로 변경한다.물론 데이터를 구분 할 수 있는 딜리미터(|@|)가 필요하다.group_concat(qc.view SEPARATOR '|@|')...group by userId 여기서 내가 원했던 기능은 질문의 순서대로 row가 정렬하고자 했던 부분이다.질문지의 ID로 group_concat을 했더니 엉망이다...ㅠ  그냥 row 레벨로 풀어서 엑셀 내보내기를 해두 된다. But 서비스 로직이 복잡해 진다.복잡해 지면 추후에 다시 볼 때 머리에 지진이 온다.해서 뭐든 최대..

일관성을 유지하기 위해 데이터 저장과 업데이트 동일하게 처리 된다.즉, ID(PK) 존재 여부로 등록하거나 업데이트를 진행 한다.  업데이트를 할 때 필요한 값만 하고 싶은 경우에 대한 고민s 방법1. @DynamicUpdate 사용하면 될 일이지만 해당 기능은 없다고 한다. 따라서 DB데이터를 가져와서 수정된 데이터를 바인딩하고 Save() 호출한다.-> DB로부터 객체를 가져오는 추가적인 접근이 필요하다.return formRepository.save(mapper.map(formQuestion.form, Form::class.java)) .flatMap { savedForm -> Flux.fromIterable(formQuestion.questions) ...

고성능 시스템을 구축하기 위해서는 필수라는데..손이 너무 많이 간다. ㅠ   최대한 한방 쿼리로 DB 자체의 요청 자제하는 방향으로 진행한다. 왜냐면 DB에서 발생하는 리소스가 높다것이다. 실상..비지니스로직에서 무한루프 준하는 프로세스가 돌지 않는이상 지연의 90%이상은 DB라고 본다. 뭐 암튼(1 : N) * N 개의 쿼리는. R2DBC에서는....설명 ..은 코드로..보자.fun searchQuestionByFormId(formId:Long): Mono{ return Mono.zip( formRepository.getFormById(formId), // (1) questionRepository.searchQuestionByFormId(formId) // ..

R2DBC는 여전히너무 단순한 형태의 API만 제공하기 때문에  페이징 처리를 위해서는 네이티브로 작성해야 한다. @Query( """ SELECT id, action, amount, regDt FROM Product WHERE userId =:userId ORDER BY regDt ASC LIMIT :pageIndex, :pageSize """ ) fun searchPointByUserId(userId: String, pageIndex: Int, pageSize: Int) : Flux ⭐⭐ 객체를 인자로 받아서 깔끔하게 바인딩 해볼라고 했더니...역시나. ㅋ 뭐 일단 낱개로 넘..

3천Row 밖에 안 되지만 본문 컨텐츠가 무거워 export할 때 용량은 거의 1GB에 육박했다. 현재 서비스를 이용하는데는 크게 문제는 없으나 추후 테이블의 구조가 변경될 때 이슈가 발생할 여지가 있기 때문에 이미 그런 경험을 맛 보았기 때문에 분리하려고 한다. 또 한편으로는 굳이(?) ㅡㅡㅋ 유비무환이다. 본문의 내용을 별도 테이블로 관리하기 때문에 장점을 또 굳이...이야기해보면. 1. 버전관리가 가능하다. 2. 메인테이블이 가벼워진다. 다시 말해 확장이 필요할 때 부담이 없어진다. 단점. 1. 관리 포인트가 많아진다. 2. 성능 문제가 예기치 못하게 발생할 수 있다. 본문이 컨텐츠가 더 커지면..파일로 관리해보자 ㅋ 가즈아!