잉여개발자

개요수치형 필드 설계시 효율적인 데이터 저장을 위해 나름의 현실에서 만들어 질 수 있는 필드들에 기준을 세워보았다.  수치형 필드 기준횟수(유한) / 일수 / 개수일반적인 (unsigned) Integer 필드DB 내부적으로 21억 이하의 정수 비즈니스 로직상으로 무한정 커질 수 없는 경우ex) 일 노출 횟수, 기간 일 수, 댓글 개수 금액 및 횟수 (무한)(unsigned) BigInteger 필드DB 내부적으로 63경 이하물론 꼭 Big 으로 필요는 없고 유연하게 하여도 됨)ex. 상품 단가, 최종 금액, 조회 수  Enum 값, 작은 단위의 값 (유한)TinyInteger, SmallInteger 필드 (일반적으로 256 또는 32767 이하) ex) 유저 타입, 상태값, 할인율 (0~100) 실..

기본 원칙무결성 - 데이터베이스 내에 모든 값은 언제나 정확한 값을 유지해야 한다.유연성 - 데이터베이스 구조는 요구사항 변화에 대해 수정이 쉬워야 한다.확장성 - 데이터베이스 구조는 기능 확장에 대해서 수정이 쉬워야 한다. 엔티티 이해유형 엔터티 : 물리적인 형태 o, ex. 상품, 회원)개념 엔터티 : 물리적인 형태 x, 개념적, ex. 부서, 학과)사건 엔터티 : 행위로 인해 발생, ex. 주문, 이벤트 응모) 기본키 생성시 자연키 vs 인조키 기본 키란 해당 레코드를 식별하기 위한 유일한 값 자연키 (DB에서 자동으로 생성해주는 것)장점 : 자동으로 인덱싱 해줌단점 : 혹여 기본키 수정해야 될 상황 발생시 문제 발생 인조키 (직접 생성 후 지정)장점 : 비즈니스 로직으로 인한 기본키 변경시에도 유..

개요상태, 유형, 타입, 등급 등의 들어갈 수 있는 값에 제한이 있는 필드들에 대해서 추가적인 참조 테이블 설계가 필요할지, 아니면 Enum 값 정도로 괜찮을지에 대한 장단 비교, 기준 등  Enum 사용시 장단점장점추가적인 테이블이 필요 없다.조인이 불필요하여 조회 속도가 빠르다. 단점Enum 값들에 연관된 추가적인 값들을 저장이 불가 (ex. 등급 이란 개념의 추가 필드, eng_name 등등)Enum 값의 변경시 코드 등도 직접 수정되어야 함 (변경시 비용이 큼) 참조 테이블로 설계시 장단점장점해당 테이블 개념에 부가적인 개념등을 테이블의 필드로 자유롭게 추가 가능하다. 제한된 값이 늘어날 때, 추가에 유연하다. 단점조인이 발생하여, 조회 속도가 저하될 수 있다.  결론핵심 기준은 유연성, 향후 변..

배경회사나 팀마다 로깅성 혹은 어떤 작업에 대한 변화 히스토리나 결과에 대해서 테이블 화 할 때 각자 정한 테이블명 규칙이 있거나 라이브러리 등 연동시 기본적으로 생성해주는 테이블명 등 혹은 개인적으로 어울린다고 생각하는 테이블 명이 있을 것 이라 생각한다. 나름의 기준으로 테이블 명 규칙을 적어보았다. log, result, history_log정의 : 시스템 레벨의 정보 저장인 경우, 시간의 흐름에 따른 경우, 일정 시간 후에 삭제 가능 경우예시- request_response_log : 요청/응답 로그- web_log : 웹 전반에서 발생하는 로그- system_log : 시스템에서 발생하는 로그- cron_log : 크론 등에서 발생하는 시스템 성 로그 _results 정의 : 작업(계산, 분석 ..

배경 API 설계시 일부 기업이나 방법론 중 모든 상태 코드를 200으로 처리하는 방법이 종종 거론되곤 한다. 관련 링크 : https://okky.kr/questions/661303 (카더라긴 하지만 댓글에 기타 정보 내용이 있음) 일반적으로 응답 코드는 요청에 대한 상태를 나타내는 HTTP 상태 코드(Status code)와, 에러에 대한 정보를 담은 세부 에러 코드(Error code)로 나뉘며 일반적인 처리는 상태 코드별로 > 세부 에러 코드를 나누는 것이 일반적이다. 위에 말한 방법은 상태 코드를 통일하고 > 세부 에러 코드로 통합 하는 것 이다. 모든 상태코드를 200으로 고정하여 처리 하는 경우 주된 목적 : HTTP Status Code가 노출 될 시 보안에 위험이 있을 수 있음 (ex...

토스페이먼츠 정책 API 버전 정책 링크 기존 버전을 수정하는 경우 (v1) 새로운 버전을 릴리즈 하는 경우 (v2, v3, v4 .. 등) 엔드 포인트 새로운 API 엔드포인트 추가 기존 API 엔드포인트 제거 파라미터 (요청) API 요청에 새로운 선택 파라미터 추가 API 요청에서 사용하는 필수 파라미터를 선택 파라미터로 변경 API 요청에 새로운 필수 파라미터 추가 API 요청의 선택 파라미터를 필수 파라미터로 변경 응답 API 응답에 새로운 필드 추가 API 응답에 사용되던 필드 삭제 API 응답 nullable 하지 않았던 필드를 nullable 변경 API 응답 필드의 데이터 타입 변경 Enum 새로운 ENUM 추가 같은 의미를 나타내는 ENUM 코드의 변경 (예: 토스결제 → 토스페이) 에..

조회 한 데이터 없음 데이터 조회 요청시, 요청 한 데이터가 없을 경우 다음과 같이 처리 할 수 있다. 1) 200 + 빈 리스트 - 올바른 경로로 호출하여 200 응답, 하지만 데이터는 없으므로 빈 값, 빈 리스트 반환 2) 특정 에러 코드 (ex. 4001, 34011) - 데이터가 없음을 특정 에러로 규정하여 에러 코드로 응답 404 에 대한 이해 사실 조회 데이터가 없음은 404 개념에 해당되는 것 같지만, 클라이언트와 서버는 404 개념에 대해 받아 들이는 것에 차이가 존재한다. 클라이언트 : 잘못된 "경로" 접근 서버 : "리소스" 존재 X 404에 대해 좀더 살펴 보면, 404는 여러 가지 기술적인 이유로 발생할 수 있다. 서버에서 애플리케이션이 일시적으로 비활성화되거나 제거됨 프록시 연결 ..

배경 API 설계시 내려가는 Schema 값이 없을 경우, 다음과 같이 처리 할 수 있다. 1) Null을 그대로 내린다. 2) Null을 정해진 기본값(빈 문자열, 빈 리스트 등)으로 치환해서 내린다. 3) Null이 들어 있는 key를 처음부터 내리지 않는다. 사례 사례 1) 한 API를 여러 경우(화면) 에서 사용하며, 여집합 필드가 존재함 ex) A 화면에서는 해당 API의 a 필드가 사용되지만, B 화면에서는 해당 a 필드가 사용되지 않음. - 여기서 화면별로 API를 처음부터 나누지 않는 이유는, UI 에 종속 되지 않는 API를 설계하기 위함 - B 화면에 대한 요청의 경우 1), 2) 중 선택 가능 사례 2) 동일 화면이지만 시점에 따라, 데이터의 특정 필드가 DB에 입력 된 적이 없는 경..

한 페이지 정보 - API 1개 vs 2개 한 페이지에 정보 내릴 때 몇 개의 API로 내릴 것인가 ex. 유저(A)의 ~ 데이터 (B) 목록 조회 API 1개 유저(A)의 데이터(B)를 묶어서 내림 http 및 db 커넥션 감소, api 수 줄이는게 좋다. API 2개 api는 페이지에 종속되면 안된다. 한 가지 함수는 한 가지 기능만 담당하는 것 처럼, 하나의 API는 하나의 정보만 담당하는 것도 좋다. 재사용성, 유지 보수에 좋다 API 이슈 있을 시 에러가 전파되지 않음 설계시 고민할 부분 API 수를 줄이는 측면에서, 해당 부분이 성능이 그렇게 까지 중요한 부분인가? 예로 관리자 서비스의 페이지 정보라면 성능보단 재사용성, 유지보수에 중점

1. 쿼리 파라미터 값 - 문자 vs 숫자 1) 문자 일 경우 ex) ?filter=inprogress endpoint url은 애초에 드러나는 것이므로 보다 직관적임 숫자 방식에 비해 임의로 데이터를 찔러보기 어려움 (해석이 비교적 어려움) 2) 숫자 일 경우 ex) ?filter=1 문자 방식에 비해 임의로 데이터를 찔러보기 쉬움 (해석이 쉬움) 결론 : 1을 조금 더 선호 2. 쿼리 파라미터 값 - 한글 문자 vs 영어 문자 1) 한글 문자 ex) ?filter=진행중 해당 '진행중'을 URL에 포함하여 요청시 변환 과정을 거침 변환 과정 : Unicode의 값 (ex. U+C21C)을 찾음 UTF-8 인코딩 (ex. 11100011, 10001000, 1011000 - 무조건 3바이트) 으로 변환..