[상속관계 매핑] 싱글 테이블 전략을 선택한 이유
·
Database
지도에 마킹이 가능한 두개의 엔티티, CultureEvent와 CulturePlace는 Mark 엔티티를 상속하고 있다.이러한 상속관계에서 선택하기 적절한 상속관계매핑전략은 조인 전략, 싱글테이블 전략 두가지가 있는데 이번에 나는 싱글테이블 전략을 선택하기로 했다. 먼저 총 3개의 상속관계 매핑 전략을 읊고 가자.🪄상속관계 매핑 전략조인 전략: 자식테이블이 부모테이블의 PK를 참조한다. 즉 자식테이블의 PK는 FK다.부모테이블은 DTYPE (구분 컬럼)을 가진다. 어떤 자식테이블을 조회해야할지 알아야 하기 때문.장점: 가장 정규화된 방법이다. 외래키 참조 무결성 제약조건도 활용 가능하고, 저장공간도 효율적으로 사용 가능하다.단점: 조회시 Join이 잦아 성능저하를 검토해야 한다. Join을 하기에 조회..
[MySQL + JPA] field 'mark_id' doesn't have a default value | 그리고 auto increment
·
Database
🪄 기본키 전략기본키는 유일한 값으로 개발자가 지정해줘도 되지만, 실무에서 보통 자동생성 방식을 따른다프로젝트 이력을 돌아보면, 나는 보통 기본키 자동 생성 전략으로 IDENTITY를 사용해왔다. 이번 프로젝트를 개발하면서 IDENTITY 사용시 field 'xxx_id' doesn't have a default value가 뜨는 것을 보고, 데이터베이스와 JPA를 다시 짚어봐야겠다는 생각이 들었다.  🪄 기본키 자동생성 전략 4가지이 기본키 자동생성 전략은 본질적으로 insert쿼리가 언제 나가느냐의 차이다.✨ AUTO아래 IDENTITY, TABLE, SEQUENCE 중 자동선택한다.✨ IDENTITY설명- 기본 키 생성을 데이터베이스에 위임한다.- insert 쿼리를 확인해보면 id에 null이..
[가상메모리:SWAP] 건드리면 터지는 2GB 서버에 서비스올리기
·
컴퓨터구조 & OS
✨ 가상 메모리어떻게든 올려야 한다면 가상메모리(swap)를 고려해볼 수 있다!물리적 RAM이 부족할 때 디스크 공간의 일부를 RAM처럼 사용할 수 있게 하는 시스템이 가상메모리이다. 스왑 영역을 늘린다는 것은, 우리 서비스 프로세스에 필요한 페이지를 RAM에 다 못올리니까 보조기억장치(스왑영역)에 적재해두겠다는 것이다. RAM이 작으니까 페이지 폴트가 무지하게 발생하는 것이므로... 디스크의 스왑 영역을 빈번하게 참조(read, write)하게 된다. 결국 디스크  I/O 연산이므로 CPU 부하를 증가시킨다. 이 방법은 잠시 서비스를 돌리기 위한 임시 방편이다.우리 팀이 지원받고 있던 서버가 종료되어서..임시로 2GB 클라우드 서버 만들어서 올려두기로 했기 때문이다 (잠시!)  ✨ 스왑 용량 늘리기시작..
컬럼 수 적절성에 대한 고민 및 테이블 분할
·
Database
🪄 요일별 운영시간 저장 형태가게의(장소의) 월화수목금토일 운영시간을 어떻게 저장하면 가장 효율적일지 고민해보았다. 결론: 운영시간 테이블을 따로 두고mon_open, mon_close, ..., sun_open, sun_close라는 총 14개의 속성에 시간을 저장해두는 방식 이유:- [open과 close 분리] 요일별 open과 요일별 close는 의미가 다르므로 open, close로 분리한다.- [요일별 분리] 모든 장소, 행사의 운영시간은 요일별로 존재한다. 결국 월화수목금토일을 검토하는 것이 공통적일 것임.- [휴무일과 운영일] 휴무일을 별도를 저장해두는 게 아니라, open 에 별도의 값을 통해 식별하면 효율적일 것임. 🪄 관련 생각들처음부터 요일별 open, close를 저장해야곘다고..
[작업5] DB: Matching 스키마 고민
·
미분류글/ㅇ
보호되어 있는 글입니다.
[작업4] RPM의 탄생
·
미분류글/ㅇ
보호되어 있는 글입니다.
⭐ 계획표
·
yyeeennyy
보호되어 있는 글입니다.
[Spring] Cache : 프로젝트에 간단히 적용해둠
·
JAVA/Application
우리 서비스에서 일관된 데이터를 불러올 때 쿼리가 나가거나 재계산하는 것이 거슬려서 이번에 스프링 캐시를 도입해봤다. 스프링은 캐시 기능을 제공한다. 스프링 캐시 기능은 트랜잭션처럼 AOP를 통해 구현했기에 어노테이션을 사용하면 된다. 일단 간단히 어노테이션만 추가해뒀다. 현업에서 EhCache, Redis, Memcached를 많이 사용하는 것 같은데 일단은 나중에 공부 및 개선하도록 하고, 이번에는 찍먹해볼 겸 어노테이션을 통한 기본기본 캐시만 해보겠다...일단 평점이랑 메뉴정보만 캐시해뒀다.곧 코드 구조도 리팩터링 예정이라.. 남은 리뷰캐시는 그때 다시 생각해보기로 한다.이제 로그에 잡다한 쿼리문이 안 보여서 좋다. 🪄공부✨ 캐시 저장소두가지 구성방식이 있다. 하나는 JVM ..
[Java][Backend] null 반환 리팩터링
·
JAVA/Application
계기: 간만에 이펙티브자바 복습했다. 아래 내용을 프로젝트에 적용해보기로 결정했다! https://splendidlolli.tistory.com/672 [이펙티브 자바] null이 아닌, 빈 컬렉션이나 배열을 반환하라 ─ 8장:메서드:Item54 null이 아닌, 빈 컬렉션이나 배열을 반환하라 null이 아닌 빈 배열이나 컬렉션을 반환하라. null을 반환하는 API는 사용하기 어렵고, 오류 처리 코드도 늘어난다. 그렇다고 성능이 좋은 것도 아니다. splendidlolli.tistory.com 🪄 리팩터링 케이스 1. return값을 사용하지 않는데 null 반환을 금지해야 할까? 아래와 같이 리턴값을 사용하지 않는 메서드라도, null을 반환하지 않게 했다. (코드의 일관성, 미래의 안정성을 근거로 ..
[Spring] AOP로 편리하게 jwt token 검증하기
·
JAVA/Application
🪄 발단카카오 로그인을 구현하면서 클라이언트로부터 token 값을 넘겨받는 api가 많이 생겼다. 현황은 이 token을 검증하지 않고 있었다. 그러나 안전한 서비스를 제공하기 위하여 우리가 가진 jwt secret key로 token을 검증할 필요가 있어보였다. 그래서 오늘 실행에 옮겼다. 사실 지금처럼 검증하지 않더라도 유효하지 않은 token이 넘어올 경우 그냥 개인정보를 제공하지 않도록 처리되어있어서 현재 우리 서비스에 token 검증은 필요하지 않을 수 있다고 생각할 수 있다. 그렇지만, 유효하지 않은 토큰이 넘어올 경우에 대한 관리를 일관된 장소에서 할 수 있다는 장점이 있다고 보았다. 더 나아가, 유효하지 않은 token일 경우에 수행되지 않아도 될 불필요한 비즈니스 로직, 디버깅 비용을 ..