실제 DB 스키마 구조를 짜다보면, FK가 거의 필수적으로 들어가게 된다. 근데 프로젝트를 진행하다가 "현업에서는 물리적으로 FK를 사용하지 않는다" 라는 이야기를 들었다. 왜지?? 일단 물리적FK가 불편했던 경험을 되짚어봤다.성능이슈물리적 FK를 걸면, 데이터베이스에
저번 내용에 이어서, 현업에서는 연관관계 매핑을 싫어한다는 것을 알았다. 나돈데.. 나돈데.. 나돈데....실제로 나도 프로젝트 할 때, 연관관계해놓지 않은 엔티티가 있었는데 그 기억이 새록새록났다.나도 싫어하지만, 이유를 알고 싫어해야하니까 좀 더 자세히 찾아보기로
IN-IT프로젝트에 좋아요와 같은 기능을 추가하고자 고민을 하다가 Redis를 사용하게 되었다. 실은 사용하게 되었다 라기 보단.. 사용해보고 싶었다! 안해봤으니까 새로운건 (조금 빡쳐두) 재밌으니까! Redis를 왜 사용해보고 싶었냐면, 캐싱서버를 이용해 데이터를
jwt는 Json Web Token의 줄임말로, Json 포맷을 이용해 payload를 사용자에 맞게 바꾸고 저장하는 Clain기반의 Web Token이다. 토큰 자체에 정보를 저장한다.구조는 Header, Payload, Signature가 있고, Base64로 인코
DDD(Domain-Driven Design) 또는 도메인 주도 설계라고 부른다. 말 그대로 도메인 위주로 설계하는 기법이다. 한마디로, 새로운 개발 패러다임..?주로 요구사항이 자주 변화해서 그 요구사항을 개발 언어로 변환하는 시간이 너무 많이 소요될 것 같을 때 쓰
지금까지 성능을 테스트한다고 하면, 많은 요청을 보냈을 때 응답까지 걸리는 시간 혹은 응답률을 주로 생각했었다. 그러나, 공부하면 공부할 수록 "성능" 이라는 것을 테스트하기엔 정말 다양한 지표들이 존재하는구나라고 느꼈다. 먼저 성능 테스트는 부하테스트와 스트레스테스트
SLASH 23 - 금융사 최초의 Zero Trust 아키텍처 도입기 https://www.youtube.com/watch?v=2V2xYeqUsWw 영상을 보고 정리한 내용 입니다.왜 보안이 높아지면 높아질수록 업무를 할 때는 불편하지? 라는 의문으로 시작하게