생각해보기
-
DB단에서 어느 수준의 쿼리까지 작성해야할까생각해보기 2024. 1. 22. 12:01
최근 DB 동시성과 효율성에 대해 공부하다보니 DB에서 생각보다 처리할수 있는 쿼리가 많음을 깨닫고 있다. queryDsl의 기능은 그 상상 이상이고... 근본적인 질문이 하나 생겼다. 그럼 DB에 날릴 쿼리는 어느 수준까지 작성해야하지? 물론 어플리케이션 코드를 깔끔하게 하기 위해 쿼리를 많이 가공할 수 있는 상황이어도 과연 그게 맞을까?? DB가 있는 이유가 뭐지? DB를 통해 쿼리를 많이 가공해서 쓰면 좋은 점은? 그 때 Trade off는? 쿼리 최적화랑 관련된 내용이긴한데... 이 글에선 해당 주제에 대해서만 간단하게 생각해보자 1. DB 단에서 쿼리로 작성하게 될 때 이점 우선 DB와 애플리케이션 사이에서 데이터가 왔다갔다 할 때 비용이 크다. 그렇기 때문에 쿼리 최적화를 하면서 상황에 필요한..
-
Auto Increment 에 대한 생각해보기생각해보기 2023. 10. 6. 09:18
그동안 MYSQL에서 InnoDB와 MyISAM 두 스토리지를 선택해서 사용했는데, 8.0 이후로는 InnoDB 기반으로 다 넘어갔다고 한다. 따라서 해당 글은 InnoDB 스토리지 기반의 MYSQL 기준으로 작성했다.(MYSQL 8.0 이후) 이전버전에는 MyIsam 스토리지도 사용해서, 조금 다른 결과가 나올수 있다. Auto Increment는 보통은 id값에 pk와 함께 많이들 거는 제약조건이다. 사용자에게 받기보다는 DB에게 알아서 중복되지 않도록 값을 증가시키려한다. 이렇게만 보면 문제 생길 것이 없는데, 그럼에도 생각해볼거리가 있다!! 데이터를 삭제 하고 난 뒤에 데이터를 추가하면 Auto-increment가 걸린 필드값에 공백이 생기는데 안생기게 할 수는 없나? 해당 테이블은 10개의 데이..
-
Getter 와 Setter 말고 다른방식으로?생각해보기 2023. 7. 18. 10:15
개인 프로젝트를 진행하면서 도메인 모델들에 대해 값을 찾을때 필드는 private 처리를 하니 Getter와 Setter를 당연시하며 무분별하게 사용했다. 그런데 최근에 객체지향을 공부하고 짰던 코드를 다시 보니 이렇게하면 캡슐화(은닉)이 다 깨지는거 아닌가? 라는 생각이 들었다. 그래서 좀 찾아보니 Getter와 Setter를 지양해야한다는 의견들이 있었다. 내가 생각했던 캡슐화(보안상)의 문제도 있었지만 다른 점도 생각해볼것이 있었다. 그리고 코드까지 바꿔보자. MVC를 배운이후 정말 아무생각없이 Service 부분에서 웬만한 로직을 다 처리하려했다. Service단에서 해당 객체의 로직을 처리하려면 Setter와 Getter가 필요했다. 네이버 뉴스를 크롤링하는 로직이다. import lombok...