자주 발생하는 시나리오입니다.주문 시스템 용 테이블 설계
정규화를 수행하면 데이터가 반복되지 않는 방식으로 테이블을 설계해야하는 경우가 있습니다.
다음 정보를 보여주는 전형적인 주문 항목의 예 :
정규화 된 데이터베이스의 예에서 주문 테이블에는 제품 테이블의 PK (제품 설명, 가격 정책 포함)가있을 것입니다.
그러나 고객이 주문한 후에 제품 가격이 증가하거나 감소 할 수 있습니다.
거래 당시의 제품 가격을 주문 테이블에 저장해야합니까?
이 유형의 문제에 대한 더 좋은 해결책이 있습니까?
정규화는 중복 정보를 줄이지 만 "중복"은 좁은 의미의 전문 용어입니다. 이 문맥에서 중복은 같은 의미의 동일한 값을 의미합니다.
"현재 가격"과 "주문한 시점의 가격"(또는 "고객이 지불하기로 동의 한 가격")은 가치가 있다고해도 같은 의미가 아닙니다. 같은.
모델을 작성하는 데는 여러 가지 방법이 있습니다. 그러나 중요한 통찰력은 당신이 가격에 대해서 이렇게 말할 때 당신이 완전히 다른 두 가지 일을 이야기하고 있다는 것입니다.
정확합니다. OrderLine 테이블을 사용하여 각 행을 주문에 저장합니다. Prodcut이 판매 된 가격을 저장하십시오. 또한 주어진 할인을 보관할 수도 있습니다.
Catcall의 대답은 멋지다. 정답을 주어야합니다. 그러나 요점을 확장하려면 열 이름도 달라야합니다. 같은 이름을 가진 두 개의 테이블에 두 개의 열이있는 경우 그 테이블의 데이터가 동일한 것을 의미합니다. '가격'이라는 열을 가짐으로써 모델을 이해하려는 모든 사용자에게 도움이되지 않습니다. Extended_price, Price_at_sale, MSRP 등은 모두 한눈에 데이터를 이해하는 데 도움이됩니다.
쿠폰/할인/bogo 쿠폰/번들을 어떻게 고려할 것입니까? 내가 5 달러에 물건을 살 경우 1 달러짜리 쿠폰이 있으면. 5 달러 또는 4 달러에 해당 제품을 판매 했습니까? $ 5라고 말하면 $ 1에 대한 세부 테이블에 별도의 품목이있을 수 있지만 해당 제품의 수익성을 연구하면 할인을 놓칠 수 있습니다.
한 가지 : ** 예약 된 SQL 키워드 ('ORDER BY'와 같이) 때문에 ** 주문 ** 테이블을 호출하지 마십시오. '주문'또는 다른 이름으로 전화하십시오! –
@marc_s Nooooo 내 테이블 이름을 복수화하지 마십시오! – Yuck
@Yuck : 그럼, 'OrderHead' 또는 뭐라고 부르세요 ..... –