[Villion] 이 책과 함께 구매한 도서 목록 구현하기

특정 책에 관심이 있어 클릭해서 상세페이지에 들어갔을 때, 클릭했던 책을 거래한 사람이 함께 거래했던 책을 추가적으로 보여주고 싶었다.

유사한 관심사를 가진 사용자에게 함께 거래한 책을 추천함으로써 거래율을 증가시킬 수 있을 것이라 기대했기 때문이다.

 

 

주문을 할 때에 아래처럼 값을 보내주고 있다.

orderList를 그대로 DB에 저장하고 싶지만, DB에 객체를 넣어줘야해서 보기가 불편할 것 같았다.

 

{
    "renterUserId" : 1,
    "userName": "John Doe",
    "phoneNumber": "1234567890",
    "address": "123 Main St, Cityville, ST 12345",
    "deliveryMemo": "Leave at the front door.",
    "rentalStartDate": "2024-06-15",
    "rentalEndDate": "2024-06-20",
    // "totalRentalQuantity": 3,
    "shippingCost": 5000,
    // "totalRentalPrice": 15000,
    "usedPoints": 2000,
    "orderList": [
        {
            "productId": 1,
            // "productName": "Book A",
            "quantity": 2
            // "price": 100
        },
        {
            "productId": 4,
            // "productName": "Book B",
            "quantity": 5
            // "price": 200
        }
    ],
    "paymentMethod": "CREDIT_CARD"
}

 

 

 

방법 1. orderList를 저장하는 DB를 만들어서 같이 주문한 도서 목록을 구한다.

장점

1. 정확한 데이터 관리: 주문마다 고유한 식별자를 부여하고, 주문 내역을 명확히 구분할 수 있어 데이터의 무결성을 보장한다.
2. 유연한 데이터 조회: 특정 주문에 대한 상세 내역을 쉽게 조회할 수 있다.
3. 확장성: 추가적인 주문 관련 정보(예: 할인 정보, 주문 상태 등)를 쉽게 확장할 수 있다.

단점

1. 복잡한 구조: 별도의 주문 테이블과 주문 항목 테이블을 관리해야 하므로 데이터베이스 설계가 다소 복잡해질 수 있다.
2. 추가 저장 공간 필요: 모든 주문 내역을 저장해야 하므로 데이터베이스 저장 공간이 더 많이 필요할 수 있다.

 

 

방법 2. 유저와 주문일이 동일한 것을 한 내역이라고 가정하고, 이때 같이 주문한 도서 목록을 보여준다.

장점

1. 간단한 구현: 별도의 주문 테이블 없이도 유저와 주문일을 기준으로 쉽게 주문 내역을 구분할 수 있다.
2. 빠른 초기 개발: 시스템 초기 개발 단계에서 빠르게 구현할 수 있다.

단점

1. 정확성 문제: 주문일이 같더라도 다른 주문이 있을 수 있어 데이터의 정확성이 떨어질 수 있다.
2. 확장성 한계: 추가적인 주문 관련 정보를 관리하기 어려울 수 있다.
3. 데이터 무결성: 정확한 주문 내역을 보장하기 어렵기 때문에 데이터의 무결성이 저하될 수 있다.

쿼리 예시.

SELECT DISTINCT r2.bookName, r2.productId
FROM rentals r1
JOIN rentals r2 ON r1.renterUserId = r2.renterUserId AND r1.orderedAt = r2.orderedAt
WHERE r1.productId = :currentProductId
AND r2.productId != :currentProductId;

 

 

 

간편하고 빠르게 할 수 있는 방법2로 하려고 했지만,

아무래도 데이터 무결성(해당 책을 거래한 사용자가 함께 거래한 책이이 아닐 수도 있음. userID와 주문일이 같으면 같은 주문내역이라고 가정하기 때문에)이 보장되지 않는 다는 점이 걸렸다.

뿐만 아니라 나중에는 주문 내역별로 쿠폰발급, 주문 상태 관리, 고객 리뷰, 반품 및 교환, 고객 연락처 정보(주문마다 받는 사람이 달라 주문마다 연락처를 다르게 설정할 수도 있기 때문에), 배송 주소 관리 기능을 넣어 확장을 해보고 싶기 때문에 방법 1로 하기로 했다.

 

 

그럼, 방법1에서

방법 1-1.

orderEntity를 DB를 만들어서 orderList를 따로 만들것이냐,

방법 1-2.

아니면 RentalEntity에 orderList를 직접 추가할 것이냐가 고민이 된다.

 

하지만, orderEntity를 따로 만들어서 rentalEntity와 관계를 설정하는 것이 나중에 기능 확장 하는 데에 있어서 구조가 유연해질 것이기 때문에 방법 1-1을 사용했다.