life is egg
23.01.16 [줍줍줍줍줍줍줍줍줍줍줍줍줍..................] 본문
뭔가 삭제 하는ㄴ것 ...
find를 서비스에서 하면 안됨.. 한번에 너무 많은 메모리 사용함
그니까 적당히 나눠서 보내야함 ??
한꺼번에 모든 데이터가 보내면 안됨
방법
1. 쪼개서 보내기
2안불러와서 삭제시키기
>> 저장소에서 삭제하면 ..? 저장소 기능을 위반하는건가 ?!
>> SQL을 직접 ...날린다 ..?
>그니까 10만개의 댓글을 일일히 삭제하는게 아니라
>댓글을 가지고잇는 포스트 id를 삭제시킨다... 그러면 됨???
현실..실무에서는
삭제라는거 자체를 ..별로안함..
그러면 삭제는 플래그를 박아....
배치가 돌면서 .... 플래그가 달려있는거... 적당히 나눠서 불러와서
SQL in쿼리 ~ where 조건 ...천개씩 불러... 분산해서 처리 ..
oneToMany는... 매니쪽에... 갯수가 적다고 느껴지는것..!:;;임 ! !! ! ! ! ><
ex) 주문..주문목록 ... 주문에 ~ 주문목록은 1000개 넘어도 미친거지 ~ 앎 ~ 미친거야 ~
이럴때...oneToMany...
그니까.... 뭔가를 지울때.... find후 delete하는 건문제..?
그니까 바로 delete날리는 쿼리는 밑에 있는거...이건 DB과부하..!
윈윈하려면 천개씩 쪼개....

근데 실시간으로 해야함 ?
그러면... 사용사를 속이셈... 플레그박고
나머지...를 위에쓴것처럼 새벽에 .. 천개씩 나눠서 쪼개서 삭제?? !
DTO 만들때 빼고는 get을 사용하지마..
get을 사용한다면 ........ 일을 시킬수 있다는 말이야 !
---
jwt토큰은 있으면 그자체로 인증된거 맞아 .. 신뢰할 수 있는 정보야 ... DB접근 안해도 됨 ...
리프레쉬토큰도 마찬가지야 ?!
어세스토큰은...
리프레쉬랑..어세스..............도도체 뭐냐고 .~
다들 뭔가 많이 아냐고 ....
레디스?가뭐임? 이걸 선정해 ? 근거는 ? 리프레쉬토큰이 탈취되면 리보크?하기위해서 ...?
레디스를 쓰겠다 ? 내가 (서버가 ~) 관리 하겠다 ... ...<보안이 굉장히 굉장히 굉장히 중요할 때 .. !! >
~
은증이라는 관점에서는 레디스를 안써도됨 .. ?
jwt같은거 한번 보내면 끝
장점은 DB접근을 안하는 것 ,,,!
만약에 DB에 접근을 한다면 ... 그만큼의 이유가 있어야함 ...

항상 뭔가의 기능을 선택할때 왜 쓸까라는 생각을 해야함 !!
세션방식도 있음 .. !
인쿼리가 도도체 뭐임 ...!?

이건 뭘까 ...... ?!....뭐... 객체를 날린다는 말이있고 id를 날린다는 말이 있고 ...
베치in은 인쿼리이다 ....
엔티티를 리턴해지 말라 ~
상속
유저 >셀러 ,,고객 > 이거...
유저를 상속한 셀러 고객
테이블은 유저에다가 다 박아놓고 ..?
엔티티는? 다 쪼개지는게 맞음?
상속
상속 // 성격이 비슷한거는 셀러와 고객 /// 그리고 어드민계정은 별도 ...

추상화해서 .. 공통기능을 유저로 빼자 ... ! 그리고 어드민 테이블을 따로 만들자...
유저테이블을 만들고,,, 유저는 일반유저와 셀러에 공통적인거..............넣고 ....
유저......셀러 기능을 분리 .. ! 하자 ...! ! ! ! ! ! ! ! ! ! ! 1
키워드 .. jpa상속 ...
기타사진들
'TIL' 카테고리의 다른 글
| 23.01.18 [@OnDelete] (0) | 2023.01.19 |
|---|---|
| 23.01.18 [ResponseEntity....및..잡다한것] (0) | 2023.01.18 |
| 23.01.14 [리펙토링..] (0) | 2023.01.14 |
| 23.01.12 [SQL4일차] (0) | 2023.01.13 |
| 23.01.12 [SQL 3일차] (1) | 2023.01.12 |



