본문 바로가기

WEB/Error

돈 관련 필드 타입

BudgetKeemi 프로젝트에서의 고민

BudgetKeemi는 사용자가 자신의 수입과 지출을 관리할 수 있는 웹 어플리케이션이다.

예산 설정, 월별 수입/지출 확인, 지출 통계 등의 기능을 포함한다.

 

처음에 ERD를 설계할 때 가장 고민했던 건 돈 관련 필드는 타입을 어떻게 지정해야할까? 였다.

후보로는 int, long, float, double , BigDecimal 등이 있었다.


BigDecimal에 대해 알게 된 점

BigDecimal은 조사하면서 알게된 타입이다.

특징은 불변 성질을 가지고 있고 매우 큰 숫자도 표현할 수 있다는 것이다.

BigDecimal은 큰 숫자를 배열에 나누어서 저장하고 내부적으로 임의 정밀도 연산을 사용해 계산을 아주 정확하게 할 수 있다. 

금융 계산에 필수적인 타입이다.

그러나 기본 타입에 비해 속도가 느리고 어렵다는 단점이 있다.

특히 연산할 때마다 새로운 객체를 생성하기 때문에 성능이 떨어질 수 있다.


int를 선택한 이유

처음에 내가 계획한 기능 중에서 소수점을 이용하는 로직은 없었고, 음수 양수카테고리(Income,Expense)로 분류해서 나누어 처리할 생각이었다.

그래서 가장 익숙한 int를 사용했다

account의 테이블 정보

 

 

DB는 h2를 사용했다.

show columns from ACCOUNT

 

금액 범위에 대한 고민

하지만 시간이 지나고 금액 범위에 대한 고민이 생겼다.

만약 큰 금액을 처리해야한다면 long을 사용하는 게 맞았을 것이다.

 

보통 JPA에서는 intINTEGER(4byte), longBIGINT(8byte)로 매핑한다

*식별자(id) 또한 일반적으로 long을 쓴다

 

그래서 금액 칼럼의 타입을 변경하기로 결정했다.

 

변경된 account의 테이블 정보

alter table account alter column balance bigint

 


배운 점

다행히 금액 필드의 타입을 바꾸는 건 큰 문제가 없었다 (INTEGER -> BIGINT)

그러나 프로젝트에 있는 모든 금액관련 필드를 int에서 long으로 바꾸는 번거로운 작업이 필요했다. 

이 경험을 통해 ERD를 설계할 때 한번 더 신중하게 생각해야함을 깨달았다.

 

 

참고자료

https://dev.gmarket.com/75

 

BigDecimal A to Z: 정확한 계산을 위한 숫자 처리 클래스

안녕하세요. Club & Discount Engineering 팀에서 지마켓 할인/쿠폰 개발 업무를 맡고 있는 윤영택입니다. 저희 팀은 할인/쿠폰/수수료 등 돈과 관련된 도메인을 다루다 보니 코드를 작성할 때 BigDecimal

dev.gmarket.com

 

'WEB > Error' 카테고리의 다른 글

@NotNull @NotEmpty @NotBlank  (0) 2024.09.21
클라이언트? 서버? 구현 문제  (1) 2024.09.21
서비스 계층 간의 의존성  (0) 2024.09.20
FileZilla &EC2  (0) 2024.04.14