life is egg

23.01.16 [줍줍줍줍줍줍줍줍줍줍줍줍줍..................] 본문

TIL

23.01.16 [줍줍줍줍줍줍줍줍줍줍줍줍줍..................]

삶은계란진재혁 2023. 1. 16. 22:39

뭔가 삭제 하는ㄴ것 ...

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
Comments