예를 들어, 위와 같은 화면은 프론트엔드에서 렌더링 하기 위해서 적절한 JSON 포맷의 응답 메시지가 필요한 상황이다. 이 경우 아래와 같은 JSON 데이터를 받을 수 있다.
{
"hash": "H9881",
"data": {
"top_image": "https://example.com/product/H9881/top_image.jpg",
"thumb_images": ["https://example.com/product/H9881/thumb_image1.jpg",
"https://example.com/product/H9881/thumb_image2.jpg",
"https://example.com/product/H9881/thumb_image3.jpg"]
"product_description": "썬키스트 고당도 오렌지",
"cash": 134,
"delivery_info": "오늘(수) 4/21 오후 6시 전 도착 보장(오전 10시 전 주문 시/서울・경기 기준)",
"delivery_fee": 2500,
"prices": [17130, 13400],
"detail_section": ["https://example.com/product/H9881/detail_image1.jpg",
"https://example.com/product/H9881/detail_image2.jpg",
"https://example.com/product/H9881/detail_image3.jpg",
"https://example.com/product/H9881/detail_image4.jpg"]
}
}
위의 예시 데이터를 보면, 썸네일 이미지들의 url 목록을 저장하는 thumb_images
와 할인 전/후의 가격을 저장하는 prices
, 그리고 상세 이미지들의 url 목록을 저장하는 detail_section
이 모두 배열의 형태로 프론트로 전달된다. JSON 데이터의 포맷만 보면 분명히 배열이 하나의 칼럼에 속해있는 형태로 전달된다는 것을 알 수 있다.
배열을 그대로 하나의 레코드에 저장할 수는 없다. 왜냐하면 이는 제1정규형에 위반되므로 기본적으로 RDBMS에서 제한한다.
그렇다면 이것을 MySQL과 같은 RDBMS를 통해 저장하기 위해서 우선적으로 떠오르는 방법은 두 가지 이다.
첫 번째는 해당 데이터에 대한 별도의 테이블을 구성하고 쿼리문의 조인을 통해 DTO를 구성하는 방법이다.
두 번째는 그냥 배열 형태의 데이터를 통째로 String으로 변환 후 DB에 저장하고 꺼내올 때는 String을 파싱하여 List에 담아서 보내는 것이다.