지도에 마킹이 가능한 두개의 엔티티, CultureEvent와 CulturePlace는 Mark 엔티티를 상속하고 있다.이러한 상속관계에서 선택하기 적절한 상속관계매핑전략은 조인 전략, 싱글테이블 전략 두가지가 있는데 이번에 나는 싱글테이블 전략을 선택하기로 했다. 먼저 총 3개의 상속관계 매핑 전략을 읊고 가자.🪄상속관계 매핑 전략조인 전략: 자식테이블이 부모테이블의 PK를 참조한다. 즉 자식테이블의 PK는 FK다.부모테이블은 DTYPE (구분 컬럼)을 가진다. 어떤 자식테이블을 조회해야할지 알아야 하기 때문.장점: 가장 정규화된 방법이다. 외래키 참조 무결성 제약조건도 활용 가능하고, 저장공간도 효율적으로 사용 가능하다.단점: 조회시 Join이 잦아 성능저하를 검토해야 한다. Join을 하기에 조회..

🪄 기본키 전략기본키는 유일한 값으로 개발자가 지정해줘도 되지만, 실무에서 보통 자동생성 방식을 따른다프로젝트 이력을 돌아보면, 나는 보통 기본키 자동 생성 전략으로 IDENTITY를 사용해왔다. 이번 프로젝트를 개발하면서 IDENTITY 사용시 field 'xxx_id' doesn't have a default value가 뜨는 것을 보고, 데이터베이스와 JPA를 다시 짚어봐야겠다는 생각이 들었다.  🪄 기본키 자동생성 전략 4가지이 기본키 자동생성 전략은 본질적으로 insert쿼리가 언제 나가느냐의 차이다.✨ AUTO아래 IDENTITY, TABLE, SEQUENCE 중 자동선택한다.✨ IDENTITY설명- 기본 키 생성을 데이터베이스에 위임한다.- insert 쿼리를 확인해보면 id에 null이..

✨ 가상 메모리어떻게든 올려야 한다면 가상메모리(swap)를 고려해볼 수 있다!물리적 RAM이 부족할 때 디스크 공간의 일부를 RAM처럼 사용할 수 있게 하는 시스템이 가상메모리이다. 스왑 영역을 늘린다는 것은, 우리 서비스 프로세스에 필요한 페이지를 RAM에 다 못올리니까 보조기억장치(스왑영역)에 적재해두겠다는 것이다. RAM이 작으니까 페이지 폴트가 무지하게 발생하는 것이므로... 디스크의 스왑 영역을 빈번하게 참조(read, write)하게 된다. 결국 디스크  I/O 연산이므로 CPU 부하를 증가시킨다. 이 방법은 잠시 서비스를 돌리기 위한 임시 방편이다.우리 팀이 지원받고 있던 서버가 종료되어서..임시로 2GB 클라우드 서버 만들어서 올려두기로 했기 때문이다 (잠시!)  ✨ 스왑 용량 늘리기시작..

이번 주제는 주력 언어에 대한 생각을 해보는 좋은 시간이었다. 자바로 꾸준히 개발을 하면서 머릿속에 자리하게 된 하나의 개념이 있다면, 추상화다. [특징] 자바 하면 떠오르는 것은 객체지향이다. 나는 스파게티처럼 어지러운 코드를 의식적으로 지양한다. 그래서 코드를 짜기 전 큰 구조를 그려보는 것을 좋아하는데, 이것이 자바가 지향하는 객체지향과 유사한 맥락이라고 생각한다. 결국 프로그램이 깔쌈하게 돌아가려면 분리를 잘 해나가야 한다. 분리를 잘 하다보면 결국 추상화를 제대로 하게 되는 것 같다. 자바 프로그래밍을 하면서 이 추상화라는 것이 참 매력적이고 주요한 개념임을 느꼈다. 왜냐하면 프로그래밍뿐만 아니라 다른 학문에서 배우는 새로운 개념들, 아니면 일상생활에서 겪는 사건을 머릿속에 입력할 때, 추상화를..

🪄 요일별 운영시간 저장 형태가게의(장소의) 월화수목금토일 운영시간을 어떻게 저장하면 가장 효율적일지 고민해보았다. 결론: 운영시간 테이블을 따로 두고mon_open, mon_close, ..., sun_open, sun_close라는 총 14개의 속성에 시간을 저장해두는 방식 이유:- [open과 close 분리] 요일별 open과 요일별 close는 의미가 다르므로 open, close로 분리한다.- [요일별 분리] 모든 장소, 행사의 운영시간은 요일별로 존재한다. 결국 월화수목금토일을 검토하는 것이 공통적일 것임.- [휴무일과 운영일] 휴무일을 별도를 저장해두는 게 아니라, open 에 별도의 값을 통해 식별하면 효율적일 것임. 🪄 관련 생각들처음부터 요일별 open, close를 저장해야곘다고..

좋은 기회로 에 참여하게 되었다. 첫번째 글 주제는 "나는 왜 개발자가 되고 싶을까"... 허억.. 원래 나였으면 블로그에 공개하기에는 살짝(매우) 어려운 주제지만 이참에 박제해보는 것도 나쁘지 않을 듯하다. . . 아래 순서로 얘기를 해보겠다. 1. 성향 얘기 (주저리) 2. 결정 시점 3. 개발자가 되고싶은 이유 1. 성향 얘기 -- 창작 무엇이든 만들기를 좋아했다. 나름의 창작을 좋아했다고 할 수 있겠다. 손재주도 좋았다. 종이접기, 모형 만들기, 나만의 미니어쳐 (ex: 햄스터 마을...ㅋㅅㅋ 윽 부끄러), 나만의 그림 등.. 나름의 퀄리티에 신경쓰면서 누구나 우와아 할 만한 작품을 짜잔 하는 것을 좋아했다. 창의적이고 섬세한 작품을 내는 것을 뿌듯해했다. 특히 누구나 칭찬할 만한 결과물을 말이다..

보호되어 있는 글입니다.

보호되어 있는 글입니다.

보호되어 있는 글입니다.

우리 서비스에서 일관된 데이터를 불러올 때 쿼리가 나가거나 재계산하는 것이 거슬려서 이번에 스프링 캐시를 도입해봤다. 스프링은 캐시 기능을 제공한다. 스프링 캐시 기능은 트랜잭션처럼 AOP를 통해 구현했기에 어노테이션을 사용하면 된다. 일단 간단히 어노테이션만 추가해뒀다. 현업에서 EhCache, Redis, Memcached를 많이 사용하는 것 같은데 일단은 나중에 공부 및 개선하도록 하고, 이번에는 찍먹해볼 겸 어노테이션을 통한 기본기본 캐시만 해보겠다...일단 평점이랑 메뉴정보만 캐시해뒀다.곧 코드 구조도 리팩터링 예정이라.. 남은 리뷰캐시는 그때 다시 생각해보기로 한다.이제 로그에 잡다한 쿼리문이 안 보여서 좋다. 🪄공부✨ 캐시 저장소두가지 구성방식이 있다. 하나는 JVM ..