ตารางคำสั่งอีคอมเมิร์ซ ประหยัดราคาหรือใช้ตารางการตรวจสอบ / ประวัติ?

ฉันออกแบบคีมาอีคอมเมิร์ซแรกของฉัน ฉันได้อ่านเรื่องนี้มาระยะหนึ่งแล้วและสับสนเล็กน้อยเกี่ยวกับความสัมพันธ์ระหว่างorder_line_itemกับproduct

productสามารถรับการสั่งซื้อ มันมีรายละเอียดที่แตกต่างกัน unit_priceแต่ที่สำคัญที่สุดคือ

order_line_itemมีคีย์ต่างประเทศไปproduct_idซื้อที่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) ได้หรือไม่ ฉันสงสัยว่าฉันกำลังรวมแนวคิดจำนวนมากเข้าด้วยกันหรือไม่

ดังที่คุณได้ระบุไว้การจัดเก็บราคาในการสั่งซื้อทำให้การใช้งานด้านเทคนิคง่ายขึ้น มีสาเหตุหลายประการที่ทำให้เรื่องนี้มีประโยชน์

นอกจากการทำธุรกรรมผ่านเว็บแล้วธุรกิจจำนวนมากสนับสนุนการขายผ่านช่องทางอื่นเช่น

• ทางโทรศัพท์
• ตัวแทนขาย "บนถนน"
• ในสถานที่จริง (เช่นร้านค้าสำนักงาน)

ในกรณีเหล่านี้อาจมีการป้อนคำสั่งเข้าสู่ระบบในบางครั้งหลังจากทำธุรกรรม ในสถานการณ์เหล่านี้มันเป็นเรื่องยากที่จะเป็นไปไม่ได้ที่จะระบุได้อย่างถูกต้องว่าควรใช้บันทึกราคาในอดีตใด - การจัดเก็บราคาต่อหน่วยโดยตรงตามคำสั่งเป็นเพียงตัวเลือกที่เป็นไปได้

หลายช่องทางมักนำมาซึ่งความท้าทายอื่น - ราคาแตกต่างกันสำหรับผลิตภัณฑ์เดียวกัน มีค่าใช้จ่ายเพิ่มเติมสำหรับการสั่งซื้อทางโทรศัพท์เป็นเรื่องปกติและลูกค้าบางรายอาจเจรจาต่อรองส่วนลด คุณอาจสามารถแสดงราคาที่เป็นไปได้ทั้งหมดสำหรับแชแนลทั้งหมดในสคีมาผลิตภัณฑ์ของคุณ แต่การรวมสิ่งนี้ลงในตารางใบสั่งซื้อของคุณอาจกลายเป็นเรื่องซับซ้อน (มาก)

ทุกแห่งที่อนุญาตให้มีการเจรจาได้ยากที่จะเชื่อมโยงประวัติราคากับราคาที่ตกลงกันไว้ (เว้นแต่ตัวแทนจะมีข้อ จำกัด การเจรจาที่แคบมาก) คุณต้องเก็บราคาในการสั่งซื้อเอง

แม้ว่าคุณจะสนับสนุนเฉพาะธุรกรรมทางเว็บและมีโครงสร้างการกำหนดราคาที่ค่อนข้างง่าย แต่ก็ยังมีปัญหาที่น่าสนใจที่จะเอาชนะได้ - ควรจัดการราคาที่เพิ่มขึ้นสำหรับธุรกรรมเที่ยวบินอย่างไร ธุรกิจยืนยันว่าลูกค้าจะต้องจ่ายเพิ่มขึ้นหรือพวกเขาเคารพราคาเดิม (เมื่อเพิ่มสินค้าลงในตะกร้า) หรือไม่ หากเป็นการดำเนินการทางเทคนิคที่ซับซ้อน - คุณต้องหาวิธีที่จะทำให้แน่ใจว่าคุณกำลังรักษาเวอร์ชันราคาในเซสชั่นอย่างถูกต้อง

ในที่สุดธุรกิจจำนวนมากเริ่มใช้การกำหนดราคาแบบไดนามิกสูง อาจไม่มีราคาคงที่หนึ่งรายการสำหรับผลิตภัณฑ์หนึ่ง ๆ ซึ่งจะคำนวณที่รันไทม์เสมอตามปัจจัยต่าง ๆ เช่นเวลาของวันความต้องการผลิตภัณฑ์และอื่น ๆ ในกรณีเหล่านี้ราคาอาจไม่ถูกเก็บไว้กับผลิตภัณฑ์ในตอนแรก!

ฉันจะเพิ่มคะแนนจริงที่ฉันได้เห็น

1. ผลิตภัณฑ์ชั่วคราว

   สิ่งที่พวกเขาอาจมีความหมายในวันนี้อาจจะไม่เหมือนกับสิ่งที่พวกเขาเคยมีความหมายปี รหัส sku เดียวกัน (และด้วยเหตุนี้ product_id) อาจหมายถึงตัวแปร / ชนิดของผลิตภัณฑ์ที่แตกต่างกันในแต่ละขั้นตอน

   ทุกคนไม่เข้าใจความกังวลทั้งหมดที่อยู่ในมือ; ดังนั้นผู้ใช้อาจเปลี่ยนแอททริบิวต์ของผลิตภัณฑ์ดั้งเดิมแทนที่จะสร้างสิ่งใหม่จากความไม่รู้ของตัวเอง หลายครั้งสิ่งนี้อาจเกิดขึ้นเนื่องจากแผนการที่ผู้ใช้เปิดอยู่ (เฮ้! ฉันสามารถมี 100 sku เท่านั้นดังนั้นทำไมไม่เปลี่ยนรุ่นเก่าแทนที่จะอัพเกรดแผน) ดังนั้นคุณจะเห็นในรถเข็นจำนวนมาก ผลิตภัณฑ์จะไม่เคยมีความหมายเหมือนกันตลอดไป

2. ราคาแตกต่างกันขึ้นอยู่กับการสั่งซื้อและเงื่อนไขการจัดส่ง

   ตามที่ผู้ใช้ @Chris ได้กล่าวถึงราคาอาจแตกต่างกันในสถานการณ์ที่แตกต่างกัน

   ในเกวียนส่วนใหญ่คุณจะพบฟิลด์อย่างน้อย 3 ฟิลด์ที่เก็บไว้ - ราคาต่อหน่วยจำนวนส่วนลดและราคาลดพิเศษ ในขั้นสูงกว่าคุณจะพบอีก 2 - ราคาต่อหน่วยพร้อมภาษีราคาลดพร้อมภาษี คุณอาจพบฟิลด์อีกสองสามฟิลด์เพื่ออธิบายค่าใช้จ่ายวิธีการจัดส่งและวิธีการชำระเงินเพิ่มเติม ร้อยละภาษีอาจแตกต่างกันไปขึ้นอยู่กับรัฐผลิตภัณฑ์ประเทศวิธีการจัดส่งและอื่น ๆ และอื่น ๆ ที่เป็นหัวหน้าต้นทุน ในทำนองเดียวกันส่วนลดอาจแตกต่างกันไปขึ้นอยู่กับภูมิศาสตร์โปรโมชั่นเวลาในการขายและอื่น ๆ ดังนั้นจึงมีข้อมูลที่สามารถรับได้ในระดับคำสั่งซื้อเท่านั้นและข้อมูลที่รวมกันนี้ไม่สามารถสร้างจากข้อมูลในตารางผลิตภัณฑ์เพียงอย่างเดียว

3. แยกความกังวล

   มีการใช้รถเข็นจำนวนมากเพื่อให้ทีมต่าง ๆ สามารถควบคุมข้อมูลส่วนต่าง ๆ ได้ บางคนจัดการระบบการสั่งซื้อไม่จำเป็นต้องรู้ว่าสินค้าทั้งหมดมีในสต็อกอะไรบ้างมีราคา ณ จุดต่าง ๆ เวลามีทางเลือกอะไรสำหรับ sku ที่ระบุและอื่น ๆ การเก็บข้อมูลที่เกี่ยวข้องกับผลิตภัณฑ์พร้อมกับข้อมูลการสั่งซื้อจะช่วยให้เกิดการแยกความกังวล สิ่งนี้อาจเป็นจริงในขั้นตอนการพัฒนาหากทีมต่าง ๆ จัดการส่วนต่าง ๆ ของระบบ

4. ปรับขยายได้ง่ายขึ้นในหลาย ๆ ระบบ

   บ่อยครั้งที่ระบบการจัดการคำสั่งซื้อ, Rule Engine, แคตตาล็อกเครื่องยนต์, ระบบจัดการเนื้อหาล้วนถูกสร้างขึ้น / ดูแลเป็นระบบแยกต่างหากของตัวเอง สิ่งนี้จะช่วยปรับให้เหมาะสมสำหรับสภาวะโหลดที่หลากหลายและสร้างความเชี่ยวชาญพิเศษสำหรับแต่ละระบบ จากนั้นระบบหนึ่งจะไม่สามารถเรียกค่าไถ่ได้เนื่องจากไม่มีข้อมูลจากระบบอื่น

5. การพัฒนาและเวลาทำงานที่รวดเร็วขึ้น

   ฉันใช้คำว่า "เวลาในการพัฒนา" ที่นี่ แต่การใช้ "เวลาดีบัก" จะเหมาะกว่า เมื่อใดก็ตามที่มีการพัฒนาใหม่เกิดขึ้นมันจะเร็วขึ้นหากข้อมูลที่ต้องการนั้นมีอยู่โดยไม่เพิ่มความซับซ้อนของตัวเองเพราะจะมีวงจรการดีบักที่ค่อนข้างเล็กกว่า

   ลองนึกภาพคุณถูกขอให้สร้างรายงานตามความต้องการเพื่อรับส่วนลดที่เสนอให้ในแต่ละวันสำหรับเดือนที่กำหนดย้อนหลังครึ่งปี หากคุณมีราคาดั้งเดิมราคาลดในตาราง 1-2 พร้อมกับการสั่งซื้อรายละเอียดการสั่งซื้อสินค้านี้ค่อนข้างตรงไปข้างหน้า อย่างไรก็ตามถ้าคุณต้องไปและดึงราคาจากตารางอื่นจากนั้นส่วนลดที่เกี่ยวข้องจากตารางอื่นและจากนั้นหารายละเอียดทั้งการพัฒนาและเวลาทำงานจะสูงขึ้น

การออกแบบที่ดีควรพยายามปรับให้เหมาะสมสำหรับอนาคตเท่าที่ควรสำหรับปัจจุบัน

อาจต้องเสียค่าใช้จ่ายในการจัดเก็บมากขึ้น แต่ฉันชอบที่จะเก็บรายละเอียดที่เกี่ยวข้องทั้งหมดของการขายด้วยการทำธุรกรรมด้วยตัวเองดังนั้นถ้าด้วยเหตุผลใดก็ตามที่หลักฐานการตรวจสอบของเราได้รับความเสียหายหรือผู้ดูแลระบบ การขายเช่น: สกุลเงินที่ใช้, ราคาต่อหน่วย, จำนวน, ภาษีที่นำไปใช้และมูลค่าที่พวกเขามาถึงและอื่น ๆ ที่มีอยู่ทั้งหมด ฉันมักจะเก็บว่าเป็น XML เพื่อให้มีความยืดหยุ่นตั้งแต่การขายจนถึงการขาย

แก้ไข: เพื่อขยายสิ่งที่ฉันพูดสั้น ๆ ข้างต้นในความคิดเห็นติดตามของฉันด้านล่างและสิ่งที่ @a_horse_with_no_name แตะที่ด้านบนความซ้ำซ้อนในข้อมูลการทำธุรกรรมไม่เพียง แต่มีความสำคัญเท่านั้น

ฉันสมมติว่าคุณกำลังสร้างโดยใช้ OOP และดังนั้นคุณน่าจะมีวัตถุธุรกรรมและทั้งวัตถุผลิตภัณฑ์ที่ครอบคลุมและ / หรือวัตถุราคา ในประสบการณ์ส่วนตัวของฉันฉันชอบที่จะพูดอย่างละเอียดในประวัติศาสตร์ของฉันการจัดเก็บค่อนข้างเงียบ

สิ่งที่เราทำคือสร้างประวัติวัตถุที่คุณสามารถอำนวยความสะดวกในการใช้ RDBMS ที่มีอยู่หรือรสชาติของการจัดเก็บค่าคีย์ NOSQL (หรือดีกว่า RDBMS ที่ช่วยให้ NoSQL เช่นการเชื่อมต่อเช่นตัวจัดการเครื่องมือหรือ memcache) และเราเก็บประวัติวัตถุ ด้วยวิธีนี้ทุกรายละเอียดและการเปลี่ยนแปลงราคาในที่เดียวสามารถทำได้อย่างง่ายดายและรวดเร็ว หากคุณจริงจังคุณสามารถใช้ DIFF เพื่อบันทึกในที่จัดเก็บและเก็บการเปลี่ยนแปลงไว้ข้างหน้าเท่านั้นแม้ว่ามันจะมีคำเตือนเป็นของตัวเอง ที่ควรดูแลประวัติของคุณและข้อดีของวัตถุที่เป็นอนุกรมคือระบบของคุณจะ / ควรจะสามารถนำพวกเขากลับมาเป็นวัตถุที่พวกเขาถูกเก็บไว้ ที่ดูแลประวัติศาสตร์

สำหรับข้อเสนอแนะของฉันการจัดเก็บรายละเอียดธุรกรรมเช่นภาษีสกุลเงิน ฯลฯ ด้วยการทำธุรกรรมนั้นหมายความว่าไม่จำเป็นต้องดูรายละเอียดเหล่านั้นวัตถุธุรกรรมของคุณจะรับรู้ถึงคุณสมบัติของมันและคุณจะสามารถดูแลการนำเสนอได้ ข้อมูลที่เปลี่ยนแปลงตามที่คุณเห็นว่าเหมาะสม คุณสามารถเข้าถึงสแน็ปช็อตได้อย่างรวดเร็วและได้รับประโยชน์เพิ่มเติมจากบันทึกที่ซ้ำซ้อนและตรวจสอบได้

มันคุ้มค่าเชื่อฉัน!

คะแนนของฉันคือการเก็บราคาต่อหน่วยในรายการโฆษณาของคุณและติดตามประวัติการกำหนดราคาของผลิตภัณฑ์ของคุณในตารางแยกต่างหาก เหตุผลของฉันสำหรับสิ่งนี้คือเพื่อเพิ่มความยืดหยุ่น

แม้ว่าโครงสร้างการกำหนดราคาของคุณจะมีความเข้มงวดและชัดเจนและไม่อนุญาตให้มีการเปลี่ยนแปลงที่ @Chris Saxon ดังกล่าวข้างต้นคุณรู้สึกสบายใจที่จะเป็นเช่นนั้นหรือไม่? แม้ว่าคุณจะมั่นใจทำไมทาตัวเองในมุม? ฉันคิดว่ามันเป็นความคิดที่ดีที่จะเก็บสิ่งนี้ไว้ในรายละเอียดของรายการโฆษณาเพราะฉันไม่สามารถนึกถึงเหตุผลที่น่าสนใจที่จะแยกมันออกจากกัน

สำหรับการจัดเก็บประวัติการกำหนดราคาของคุณมีค่าแน่นอนในการจัดเก็บแยกต่างหากเนื่องจากอาจมีการเปลี่ยนแปลงราคาของรายการและไม่มีใครซื้อ นั่นจะเป็นข้อมูลที่มีประโยชน์ที่จะรู้ว่าการเปลี่ยนแปลงราคาไม่มีประสิทธิภาพหรือไม่ ดังที่คุณกล่าวถึงนี่เป็นกรณีการใช้แบบคลาสสิกของมิติที่ 2 การเปลี่ยนมิติอย่างช้าๆในสถานการณ์จำลองคลังข้อมูล โดยทั่วไปการเปลี่ยนแปลงราคาใด ๆ ในตารางผลิตภัณฑ์ของคุณจะถูกบันทึกและแถวใหม่จะถูกเพิ่มเข้าไปในตารางมิติพร้อมด้วยราคาที่อัปเดตและการประทับเวลาเพื่อระบุว่าการเปลี่ยนแปลงนี้เกิดขึ้นเมื่อใด แถวก่อนหน้าจะมีวันที่สิ้นสุดของข้อมูลที่อัปเดตเพื่อระบุว่าไม่มีราคาที่มีประสิทธิภาพอีกต่อไป ดังนั้นวิธีหนึ่งก็คือการติดตามการเปลี่ยนแปลงประเภทนี้ในคลังข้อมูล

อย่างไรก็ตามหากคุณไม่ต้องการกังวลเกี่ยวกับการออกแบบ schema คลังข้อมูลและกระบวนการ ETL ในเวลาเดียวกันกับการออกแบบฐานข้อมูลอีคอมเมิร์ซ OLTP ของคุณประวัตินี้อาจถูกบันทึกไว้ในฐานข้อมูลอีคอมเมิร์ซของเราอย่างแน่นอน สิ่งนี้สามารถทำได้เมื่อคุณอธิบายด้วยการสร้างตาราง product_audit แยกต่างหากที่แฮงค์ออกจากตารางผลิตภัณฑ์และมีวันที่เริ่มต้นและสิ้นสุดสำหรับเมื่อเวอร์ชันของผลิตภัณฑ์นั้นมีผล นอกจากนี้ยังสามารถทำได้ในตารางผลิตภัณฑ์โดยเพิ่มวันที่เริ่มต้นและสิ้นสุดลงในตารางเพื่อระบุว่าผลิตภัณฑ์ใดกำลังใช้งานอยู่ในปัจจุบัน อย่างไรก็ตามขึ้นอยู่กับจำนวนของผลิตภัณฑ์และจำนวนหรือการเปลี่ยนแปลงการกำหนดราคาที่ บริษัท ของคุณผ่านมันอาจทำให้ตารางผลิตภัณฑ์ของคุณใหญ่กว่าที่ตั้งใจไว้และอาจทำให้เกิดปัญหาประสิทธิภาพการสืบค้นในภายหลัง

สุดท้ายการแยกประวัติการกำหนดราคาของคุณออกจากราคาต่อหน่วยที่เกิดขึ้นจริงในรายการโฆษณานั้นอาจให้โอกาสในการวิเคราะห์อื่น ๆ เพื่อดูว่าผลิตภัณฑ์ใดขายในราคาที่สูงกว่าหรือต่ำกว่าราคาที่ระบุไว้ในเวลานั้น

ฉันเห็นด้วยกับแนวคิดหลักของการเก็บข้อมูลที่เกี่ยวข้องกับการสั่งซื้อ (บริบท) ไว้ด้วยกัน เพียงเล็กน้อยที่ทราบว่าสถานการณ์ดังกล่าวจะเกิดขึ้นเฉพาะเมื่อคุณกำลังออกแบบแอปพลิเคชันของคุณเป็นศูนย์กลางฐานข้อมูลมากและทุกอย่างหมุนรอบฐานข้อมูลขนาดใหญ่ไขมัน หากคุณเปลี่ยนมุมมองของคุณโดยดูที่โดเมนปัญหาจากมุมมองที่แตกต่างคุณจะสังเกตได้อย่างชัดเจนว่าคำสั่งนั้นเป็นสแนปช็อตที่จับภาพของเหตุการณ์ที่พิเศษมากในวงจรชีวิตของแอปพลิเคชันของคุณ เมื่อคุณจัดการกับปัญหาตามบริบทปัญหาฐานข้อมูลจะกลายเป็นเรื่องรองและความซับซ้อนที่ทุกคนกลัวเกี่ยวกับการสืบค้นและการทำรายงานจะได้รับการจัดการอย่างต่อเนื่องในรูปแบบโดเมน