전자 상거래 주문 표. 가격을 저장하거나 감사 / 이력 표를 사용 하시겠습니까?

첫 번째 전자 상거래 스키마를 설계하고 있습니다. 나는 주제에 대해 잠시 동안 읽고 있었고, a order_line_item와 a 의 관계에 대해 약간 혼란 스럽 습니다.product

A product를 구입할 수 있습니다. 다양한 세부 사항이 있지만 가장 중요한 것은입니다 unit_price.

은 order_line_item받는 외래 키가 product_id1, 구입 quantity구입하고,이 unit_price시점에서 고객이 제품을 구입합니다.

내가 읽은 대부분은 unit_priceon을 order_line_item명시 적으로 추가해야 한다고 말합니다 (즉,를 통해 참조하지 않아야 함 product_id). 상점에서 향후 가격을 변경하여 주문 보고서, 추적, 무결성 등을 엉망으로 만들 수 있으므로 의미가 있습니다.

내가 이해하지 못하는 것은 왜 unit_price값을 order_line_item?

unit_price변경 사항 을 문서화하는 감사 / 기록 테이블을 작성하는 것이 좋지 product않습니까?

를 만들면 테이블 order_line_item의 외래 키 product_audit가 추가되고 가격을 참조에서 검색 할 수 있습니다.

이 접근법 (데이터 복제, 가격 변경 내역 등)을 사용하면 많은 긍정적 인 것으로 보이므로 왜 더 자주 사용하지 않습니까? 이 접근 방식을 사용하는 전자 상거래 스키마의 예를 보지 못했습니다.

UDPATE : 내 질문은 천천히 변화하는 차원 과 관련이있는 것 같습니다 . 느리게 변화하는 차원이 데이터웨어 하우스 및 OLAP과 관련되어 있기 때문에 여전히 혼란 스럽습니다. 따라서 느린 변경 차원 유형을 기본 OLTP (Business Transaction Process Database)에 적용 할 수 있습니까? 많은 개념을 혼합하고 있는지 궁금합니다. 지침에 크게 감사드립니다.

확인했듯이 주문에 가격을 저장하면 기술 구현이 쉬워집니다. 이것이 유익한 이유는 여러 가지가 있습니다.

웹 거래 외에도 많은 비즈니스에서 다음과 같은 다른 채널을 통한 판매를 지원합니다.

• 전화로
• "도로에서"판매 대리인
• 실제 위치 (예 : 상점, 사무실)

이 경우, 거래가 발생한 후 어느 시점에 주문이 시스템에 입력 될 수 있습니다. 이러한 상황에서는 어떤 과거 가격 레코드를 사용해야하는지 정확하게 식별하기가 어려울 수 있습니다. 주문시 단가를 직접 저장하는 것이 유일한 옵션입니다.

여러 채널에서 종종 같은 제품에 대해 다른 가격을 책정합니다. 전화 주문에 대한 추가 요금이 일반적이며 일부 고객은 스스로 할인을 협상 할 수 있습니다. 제품 스키마의 모든 채널에 대해 가능한 모든 가격을 표시 할 수 있지만이를 주문 테이블에 통합하면 (매우) 복잡해질 수 있습니다.

협상이 허용되는 곳이면 상담원이 협상 범위를 좁히지 않는 한 가격 내역을 합의 된 주문 가격에 연결하는 것이 매우 어려워집니다. 주문 자체에 가격을 저장해야합니다.

웹 거래 만 지원하고 가격 구조가 비교적 간단한 경우에도 극복해야 할 흥미로운 문제가 있습니다. 비행 거래에서 가격 인상을 어떻게 처리해야합니까? 사업체는 고객이 인상해야하거나 원래 가격을 존중해야한다고 주장합니까 (제품이 바구니에 추가 된 경우)? 후자의 경우 기술 구현이 복잡합니다. 세션에서 가격 버전을 올바르게 유지하는 방법을 찾아야합니다.

마지막으로, 많은 기업들이 매우 역동적 인 가격을 사용하기 시작했습니다. 특정 제품에 대해 고정 가격이 하나는 없을 수도 있습니다. 항상 시간, 제품 수요 등과 같은 요소를 기반으로 런타임에 계산됩니다. 이 경우 처음부터 제품에 대해 가격이 저장되지 않을 수 있습니다!

내가 본 몇 가지 실용적인 점을 추가하겠습니다.

1. 제품이 일시적입니다.

   그들이 오늘날 의미하는 것은 그들이 1 년 전에 의미했던 것과 같지 않을 수 있습니다. 동일한 SKU 코드 (따라서 product_id)는 다른 단계에서 제품의 다른 변형 / 종류를 나타낼 수 있습니다.

   모든 사람이 당면한 모든 문제를 이해하는 것은 아닙니다. 따라서 사용자는 자신의 무지에서 새로운 제품을 만드는 대신 원래 제품의 속성을 변경할 수 있습니다. 많은 경우에, 이것은 사용자가있는 계획으로 인해 발생할 수 있습니다 (이봐! 100 스쿠 만 가질 수 있으므로 계획을 업그레이드하는 대신 이전 버전을 계속 변경하지 않는 이유는 무엇입니까?) 그래서 많은 장바구니에 있습니다. 제품은 결코 같은 것을 영원히 의미하지 않습니다.

2. 주문 및 배송 조건에 따라 다른 가격

   @Chris 사용자가 언급했듯이, 다른 시나리오에서 다른 가격이 적용될 수 있습니다.

   대부분의 장바구니에는 최소 3 개의 다른 필드 (단가, 할인 금액 및 할인 가격)가 저장되어 있습니다. 더 고급 인 경우 세금이 포함 된 단가, 세금이 포함 된 할인 된 가격이 2 개 더 있습니다. 운송 방법 요금 및 추가 지불 방법 요금을 설명하기위한 몇 가지 필드가 더 있습니다. 세금 비율은 주, 제품, 국가, 배송 방법 등에 따라 다를 수 있으며 기타 비용 부담도 다릅니다. 마찬가지로 할인은 지역, 프로모션, 판매 시간 등에 따라 달라질 수 있습니다. 따라서 주문 레벨에서만 얻을 수있는 정보가 있으며이 결합 된 정보는 제품 테이블의 데이터에서만 생성 될 수 없습니다.

3. 우려의 분리

   많은 수의 카트가 어떤 방식으로 구현되어 서로 다른 팀이 서로 다른 데이터 부분을 제어 할 수 있습니다. 주문 시스템을 관리하는 사람은 항상 모든 제품의 재고가 무엇인지, 다른 시점에 가격이 있었는지, 주어진 sku에 대한 대안 등을 알아야 할 필요는 없습니다. 주문 데이터와 함께 제품 관련 데이터를 유지하면 문제를 분리하는 데 도움이됩니다. 다른 팀이 시스템의 다른 부분을 관리하는 경우 개발 단계에서도 마찬가지입니다.

4. 여러 시스템에서 손쉬운 확장 성

   많은 경우 주문 관리 시스템, 규칙 엔진, 카탈로그 엔진, 컨텐츠 관리 시스템이 모두 별도의 시스템으로 구축 / 유지됩니다. 이를 통해 다양한 부하 조건에 최적화하고 각 시스템에 대한 특수 인텔리전스를 생성 할 수 있습니다. 따라서 한 시스템은 다른 시스템의 정보를 사용할 수 없기 때문에 몸값을 유지할 수 없습니다.

5. 빠른 개발 및 실행 시간

   여기서는 "개발 시간"이라는 용어를 사용했지만 "디버깅 시간"을 사용하는 것이 더 적합 할 것입니다. 새로운 개발이 진행될 때마다 복잡성을 추가하지 않고 필요한 데이터를 사용할 수있는 경우 디버깅주기가 비교적 짧아 지므로 더 빠릅니다.

   반년 전 주어진 달에 대해 매일 제공되는 할인에 대한 주문형 보고서를 생성하라는 요청을 받았다고 상상해보십시오. 원래 가격, 주문, 주문 항목 세부 정보와 함께 1-2 테이블의 할인 가격이있는 경우 이것은 매우 간단합니다. 그러나 다른 테이블에서 가격을 가져 와서 다른 테이블에서 적용 가능한 할인을 가져온 다음 세부 사항을 파악해야하는 경우 개발 및 실행 시간이 더 높아집니다.

좋은 디자인은 현재와 마찬가지로 미래에도 최대한 최적화를 시도해야합니다.

스토리지 비용이 더 많이들 수 있지만 거래 자체에 판매 관련 세부 정보를 모두 보관하는 것이 좋습니다. 어떤 이유로 든 감사 추적이 중단되거나 관리자가 안전을 대체하는 경우 사용 된 통화 : 사용 된 통화, 단가, 수량, 세금 적용 및 제공된 가치 등 모두 사용할 수 있습니다. 나는 일반적으로 XML을 XML로 저장하여 판매에서 판매까지 유연하게 할 수 있습니다.

편집 : 위에서 간단히 말한 내용, 아래의 후속 의견 및 @a_horse_with_no_name이 위에서 만진 내용을 확장하려면 트랜잭션 데이터의 중복성이 중요 할뿐만 아니라 규모도 필요합니다.

나는 당신이 OOP를 사용하여 구축하고 있다고 가정하고 있으므로 트랜잭션 객체와 모든 포괄 제품 객체 및 / 또는 가격 객체가 있어야합니다. 내 개인적인 경험에서, 나는 내 역사에서 장황한 것을 선호하고, 저장 공간은 비교적 che니다.

우리가 한 일은 기존 RDBMS 또는 NOSQL 키 값 저장소의 풍미 (또는 handlersocket 또는 memcache와 같은 연결과 같은 NoSQL을 허용하는 RDBMS)를 사용하여 쉽게 사용할 수있는 객체 기록을 만들고 객체 기록을 저장하는 것입니다. 한 곳에서 모든 세부 사항과 가격이 쉽고 빠르게 변경 될 수 있습니다. 진지한 경우 DIFF를 사용하여 저장 공간을 절약하고 변경 사항을 저장할 수는 있지만 자체 경고가 있습니다. 그것은 당신의 역사를 돌봐야하며, 직렬화 된 객체의 장점은 시스템이 저장된 객체로 다시 가져올 수 있어야한다는 것입니다. 그것은 역사를 관리합니다.

내 제안과 관련하여 거래 자체에 세금, 통화 등의 거래 세부 정보를 저장하면 해당 세부 정보를 다른 곳에서 볼 필요가 없으므로 트랜잭션 객체가 속성을 인식하고 뷰를 제시 할 수 있습니다. 적합하다고 생각되는 다양한 데이터. 스냅 샷에 빠르게 액세스 할 수 있으며 중복 및 검증 가능한 레코드의 추가 이점이 있습니다.

그만한 가치가 있습니다.

본인의 투표는 광고 항목에 단가를 저장하고 제품의 가격 내역을 별도의 테이블에서 추적하는 것입니다. 이것에 대한 나의 정당성은 유연성을 높이는 것입니다.

가격 구조가 견고하고 잘 정의되어 있고 @Chris Saxon에서 언급 한 변형을 허용하지 않더라도 항상 그렇게 될 것입니까? 자신감이 있더라도 왜 구석에 자신을 페인트합니까? 광고 항목 세부 정보에이 정보를 저장하는 것이 좋은 생각이라고 생각합니다. 별도의 이유를 생각할 수 없기 때문입니다.

가격 내역을 저장하는 경우 항목의 가격이 변경되어 아무도 구매하지 않았기 때문에 별도로 저장하는 데에는 가치가 있습니다. 가격 변동이 효과가 없는지 알 수있는 유용한 정보입니다. 앞에서 언급했듯이 이는 데이터웨어 하우스 시나리오에서 유형 2 느리게 변경되는 차원의 일반적인 사용 사례입니다. 일반적으로 제품 테이블의 모든 가격 변동이 포착되고 업데이트 된 가격 및이 변경이 발생한시기를 나타내는 타임 스탬프와 함께 차원 테이블에 새 행이 추가됩니다. 이전 행에는 더 이상 유효 가격이 아님을 나타 내기 위해 종료 날짜가 업데이트되었습니다. 따라서 데이터웨어 하우스에서 이러한 유형의 변경을 추적하는 방법이 있습니다.

그러나 OLTP 전자 상거래 데이터베이스를 설계하는 동시에 데이터웨어 하우스 스키마 및 ETL 프로세스를 설계하는 데 관심을 가지지 않으려면 전자 상거래 데이터베이스에서이 히스토리를 캡처 할 수 있습니다. 이는 제품 테이블에서 중단되고 해당 버전의 제품이 적용되는 시작 날짜와 종료 날짜를 포함하는 별도의 product_audit 테이블을 작성하여 설명한대로 수행 할 수 있습니다. 제품 테이블 자체에서 시작 및 종료 날짜를 테이블에 추가하여 현재 활성화 된 제품을 표시 할 수도 있습니다. 그러나 회사의 제품 수와 가격 변경에 따라 제품 테이블이 의도 한 것보다 훨씬 더 커질 수 있으며 나중에 쿼리 성능 문제가 발생할 수 있습니다.

마지막으로 가격 항목을 광고 항목의 실제 단가에서 분리하면 제품이 당시에 제시된 가격보다 높거나 낮은 가격으로 판매 된시기를 확인할 수있는 다른 분석 기회가 확실히 제공 될 수 있습니다.

주문 관련 정보 (문맥)를 함께 유지한다는 기본 아이디어에 전적으로 동의합니다. 이러한 상황은 데이터베이스 중심의 응용 프로그램을 설계 할 때만 발생하고 모든 것이 큰 지방 데이터베이스를 중심으로 진행되는 경우에만 발생합니다. 다른 각도에서 문제 도메인을보고 관점을 전환하면 주문이 애플리케이션 수명주기에서 매우 특별한 이벤트의 캡처 된 스냅 샷임을 분명히 알 수 있습니다. 컨텍스트를 기반으로 문제를 처리하면 데이터베이스 문제가 부차적으로 복잡해지고 모든 사용자가 쿼리 및 보고서 작성을 두려워하므로 도메인 모델에서 원활하게 처리됩니다.