ฐานข้อมูลค่าแอตทริบิวต์เอนทิตีเทียบกับอีคอมเมิร์ซแบบจำลองเชิงสัมพันธ์ที่เข้มงวด

มีความปลอดภัยที่จะกล่าวว่าโมเดลฐานข้อมูลEAV / CRนั้นไม่ดี ที่กล่าวว่า

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

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

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

การอภิปรายเพิ่มเติม:

เรื่องสั้นสั้น ๆมีลิงก์ในอินเทอร์เน็ตหรือคำอธิบายแบบจำลองที่สามารถ "แก้ไข" ในเชิงวิชาการ "ในการตั้งค่าต่อไปนี้ได้หรือไม่ ฉันขอขอบคุณ Noel Kennedy ที่แนะนำตารางหมวดหมู่ แต่ความต้องการอาจมากกว่านั้น ฉันอธิบายวิธีอื่นด้านล่างโดยพยายามเน้นความสำคัญ ฉันอาจต้องการการแก้ไขมุมมองเพื่อแก้ปัญหาหรืออาจต้องเจาะลึกลงไปใน EAV / CR

ชอบการตอบสนองเชิงบวกต่อรุ่น EAV / CR เพื่อนนักพัฒนาของฉันทุกคนพูดในสิ่งที่เจฟฟรีย์เคมป์สัมผัสด้านล่าง: "เอนทิตีใหม่ต้องได้รับการจำลองและออกแบบโดยมืออาชีพ" (นำออกจากบริบทอ่านคำตอบของเขาด้านล่าง) ปัญหาคือ:

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

ลูกค้าต้องการเพิ่มแอตทริบิวต์ให้กับผลิตภัณฑ์ด้วยเหตุผลสองประการ:

• แผนก / การค้นหาคำหลัก / แผนภูมิเปรียบเทียบระหว่างผลิตภัณฑ์ที่ชอบ
• การกำหนดค่าผลิตภัณฑ์ผู้บริโภคก่อนชำระเงิน

แอตทริบิวต์ต้องมีความสำคัญไม่ใช่แค่การค้นหาคำหลัก หากต้องการเปรียบเทียบเค้กทั้งหมดที่มี "วิปปิ้งครีมฟรอสติ้ง" ก็สามารถคลิกเค้กคลิกธีมวันเกิดคลิกวิปปิ้งครีมฟรอสติ้งจากนั้นตรวจสอบเค้กทั้งหมดที่น่าสนใจโดยทราบว่ามีวิปปิ้งครีมทั้งหมด นี่ไม่ได้เจาะจงเฉพาะเค้กเป็นเพียงตัวอย่างเท่านั้น

มีข้อดีข้อเสียทั่วไปบางประการที่ฉันคิดได้มีสถานการณ์หนึ่งที่ดีกว่าอีกสถานการณ์หนึ่ง:

ตัวเลือกที่ 1 รุ่น EAV:

• Pro: ใช้เวลาน้อยลงในการออกแบบและพัฒนาแอปพลิเคชันง่ายๆ
• Pro: เอนทิตีใหม่ง่ายต่อการเพิ่ม (อาจถูกเพิ่มโดยผู้ใช้?)
• Pro: ส่วนประกอบอินเทอร์เฟซ "ทั่วไป"
• Con: รหัสที่ซับซ้อนที่จำเป็นในการตรวจสอบประเภทข้อมูลอย่างง่าย
• Con: SQL ที่ซับซ้อนกว่ามากสำหรับรายงานธรรมดา
• Con: รายงานที่ซับซ้อนแทบจะเป็นไปไม่ได้เลย
• Con: ประสิทธิภาพต่ำสำหรับชุดข้อมูลขนาดใหญ่

ตัวเลือกที่ 2 การสร้างแบบจำลองแต่ละเอนทิตีแยกกัน:

• Con: ต้องใช้เวลามากขึ้นในการรวบรวมข้อกำหนดและการออกแบบ
• Con: เอนทิตีใหม่ต้องได้รับการจำลองและออกแบบโดยมืออาชีพ
• Con: คอมโพเนนต์อินเทอร์เฟซที่กำหนดเองสำหรับแต่ละเอนทิตี
• Pro: ข้อ จำกัด ประเภทข้อมูลและการตรวจสอบที่ใช้งานง่าย
• Pro: SQL เขียนง่ายเข้าใจง่ายและดีบัก
• Pro: แม้แต่รายงานที่ซับซ้อนที่สุดก็ค่อนข้างง่าย
• Pro: ประสิทธิภาพที่ดีที่สุดสำหรับชุดข้อมูลขนาดใหญ่

ตัวเลือก 3 ชุดค่าผสม (โมเดลเอนทิตี "ถูกต้อง" แต่เพิ่ม "ส่วนขยาย" สำหรับแอตทริบิวต์ที่กำหนดเองสำหรับเอนทิตีบางส่วน / ทั้งหมด)

• Pro / Con: ต้องใช้เวลาในการรวบรวมข้อกำหนดและการออกแบบมากกว่าตัวเลือก 1 แต่อาจไม่มากเท่ากับตัวเลือก 2 *
• Con: เอนทิตีใหม่ต้องได้รับการจำลองและออกแบบโดยมืออาชีพ
• Pro: คุณสมบัติใหม่อาจถูกเพิ่มได้อย่างง่ายดายในภายหลัง
• Con: รหัสที่ซับซ้อนที่จำเป็นในการตรวจสอบประเภทข้อมูลอย่างง่าย (สำหรับแอตทริบิวต์ที่กำหนดเอง)
• Con: ส่วนประกอบอินเทอร์เฟซที่กำหนดเองยังคงต้องการ แต่ส่วนประกอบอินเทอร์เฟซทั่วไปอาจเป็นไปได้สำหรับแอตทริบิวต์ที่กำหนดเอง
• Con: SQL จะซับซ้อนทันทีที่มีการรวมแอตทริบิวต์ที่กำหนดเองไว้ในรายงาน
• Con: ประสิทธิภาพที่ดีโดยทั่วไปเว้นแต่คุณจะต้องค้นหาหรือรายงานตามแอตทริบิวต์ที่กำหนดเอง

* ฉันไม่แน่ใจว่าตัวเลือกที่ 3 จำเป็นต้องประหยัดเวลาในขั้นตอนการออกแบบหรือไม่

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

มีความปลอดภัยที่จะกล่าวว่าโมเดลฐานข้อมูล EAV / CR นั้นไม่ดี

ไม่มันไม่ใช่. เป็นเพียงการใช้ฐานข้อมูลเชิงสัมพันธ์ที่ไม่มีประสิทธิภาพ ที่เก็บคีย์ / ค่าล้วนใช้งานได้ดีกับรุ่นนี้

ต่อไปนี้เป็นคำถามที่แท้จริงของคุณ: จะจัดเก็บแอตทริบิวต์ต่างๆและให้ค้นหาได้อย่างไร?

เพียงแค่ใช้ EAV ในกรณีของคุณมันจะเป็นโต๊ะพิเศษตัวเดียว จัดทำดัชนีทั้งในชื่อแอตทริบิวต์และค่า RDBM ส่วนใหญ่จะใช้การบีบอัดคำนำหน้าในการตั้งชื่อแอตทริบิวต์ซ้ำทำให้รวดเร็วและกะทัดรัดมาก

EAV / CR น่าเกลียดเมื่อคุณใช้เพื่อแทนที่ฟิลด์ 'จริง' เช่นเดียวกับเครื่องมือทุกชนิดการใช้มากเกินไปนั้น 'ไม่ดี' และทำให้ภาพลักษณ์ไม่ดี

// ณ จุดนี้ผมอยากจะใช้เวลาสักครู่ที่จะพูดกับคุณเกี่ยวกับวีโอไอพี / รูปแบบ Adobe PSD
// วีโอไอพี / PSDไม่ได้เป็นแพลตฟอร์มอีคอมเมิร์ซดี / รูปแบบ วีโอไอพี / PSDไม่ได้เลวร้ายอีคอมเมิร์ซแพลตฟอร์ม / รูปแบบ เรียกมันว่า
// ดูถูกแพลตฟอร์ม / รูปแบบอีคอมเมิร์ซที่ไม่ดีอื่น ๆเช่น Zencart หรือ OsCommerce ไม่มีวีโอไอพี / PSDเป็นอีคอมเมิร์ซแพลตฟอร์มสุดซึ้ง / รูปแบบ มี
// ทำงานกับรหัสนี้มาหลายสัปดาห์แล้วความเกลียด Magento / PSDของฉันลุกลามกลายเป็นไฟ
// ที่แผดเผาด้วยความเร่าร้อนของดวงอาทิตย์นับล้านดวง

http://code.google.com/p/xee/source/browse/trunk/XeePhotoshopLoader.m?spec=svn28&r=11#107

โมเดลภายในนั้นแปลกประหลาดที่สุดเช่นมีใครบางคนใส่สคีมาลงในเกมที่น่ากลัวปิดผนึกและใส่ไว้ในเพนท์เพนท์ ...

โลกแห่งความจริง: ฉันกำลังทำงานเกี่ยวกับแอปการเติมเต็มมิดแวร์และนี่คือคำถามเพื่อรับข้อมูลที่อยู่

CREATE OR REPLACE VIEW sales_flat_addresses AS
SELECT sales_order_entity.parent_id AS order_id, 
       sales_order_entity.entity_id, 
       CONCAT(CONCAT(UCASE(MID(sales_order_entity_varchar.value,1,1)),MID(sales_order_entity_varchar.value,2)), "Address") as type, 
       GROUP_CONCAT( 
         CONCAT( eav_attribute.attribute_code," ::::: ", sales_order_entity_varchar.value )
         ORDER BY sales_order_entity_varchar.value DESC
         SEPARATOR '!!!!!' 
       ) as data
  FROM sales_order_entity
       INNER JOIN sales_order_entity_varchar ON sales_order_entity_varchar.entity_id = sales_order_entity.entity_id
       INNER JOIN eav_attribute ON eav_attribute.attribute_id = sales_order_entity_varchar.attribute_id
   AND sales_order_entity.entity_type_id =12
 GROUP BY sales_order_entity.entity_id
 ORDER BY eav_attribute.attribute_code = 'address_type'

ข้อมูลที่อยู่ที่แน่นอนสำหรับการสั่งซื้ออย่างเกียจคร้าน

-

สรุป:ใช้ Magento เฉพาะในกรณีที่:

1. คุณได้รับเงินจำนวนมาก
2. คุณต้อง
3. สนุกกับความเจ็บปวด

ฉันแปลกใจที่ไม่มีใครพูดถึงฐานข้อมูล NoSQL

ฉันไม่เคยฝึก NoSQL ในบริบทการใช้งานจริง (เพิ่งทดสอบ MongoDB และรู้สึกประทับใจ) แต่จุดรวมของ NoSQL คือความสามารถในการบันทึกรายการที่มีแอตทริบิวต์ที่แตกต่างกันใน "เอกสาร" เดียวกัน

ในกรณีที่ประสิทธิภาพไม่ใช่ข้อกำหนดหลักเช่นเดียวกับแอปพลิเคชันประเภท ETL EAV มีข้อดีอีกอย่างหนึ่งคือการบันทึกส่วนต่าง

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

วิธีแก้ปัญหาที่ง่ายคือบันทึกเฉพาะการเปลี่ยนแปลงที่แตกต่างของอ็อบเจ็กต์โดเมนหลักแทนที่จะบันทึกข้อมูลซ้ำ ๆ

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

ฉันกำลังดิ้นรนกับปัญหาเดียวกัน อาจเป็นเรื่องที่น่าสนใจสำหรับคุณที่จะลองดูการสนทนาต่อไปนี้เกี่ยวกับโซลูชันอีคอมเมิร์ซที่มีอยู่สองแบบ: Magento (EAV) และ Joomla (โครงสร้างเชิงสัมพันธ์ปกติ): https://forum.virtuemart.net/index.php?topic=58686.0

ดูเหมือนว่าการแสดง EAV ของ Magento จะเป็นนักแสดงที่แท้จริง

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

สถาปัตยกรรมดังกล่าวดูเหมือนจะเป็นจุดที่น่าสนใจในกรณีนี้ - มีความยืดหยุ่นและมีประสิทธิภาพในเวลาเดียวกัน

ปัญหาอาจเกิดจากการใช้ ALTER TABLE บ่อยครั้งในสภาพแวดล้อมจริง ฉันใช้ Postgres ดังนั้น MVCC และ DDL เชิงธุรกรรมหวังว่าจะช่วยบรรเทาความเจ็บปวดได้

ฉันยังคงโหวตให้มีการสร้างแบบจำลองในระดับอะตอมที่มีความหมายต่ำที่สุดสำหรับ EAV ปล่อยให้มาตรฐานเทคโนโลยีและแอปพลิเคชันที่มุ่งเน้นไปที่ชุมชนผู้ใช้บางกลุ่มเพื่อตัดสินใจรูปแบบเนื้อหาความต้องการซ้ำ ๆ ของคุณลักษณะธัญพืช ฯลฯ

หากเป็นเพียงเกี่ยวกับแอตทริบิวต์แค็ตตาล็อกผลิตภัณฑ์และด้วยเหตุนี้ข้อกำหนดในการตรวจสอบความถูกต้องสำหรับแอตทริบิวต์เหล่านั้นจึงค่อนข้าง จำกัด ข้อเสียที่แท้จริงเพียงประการเดียวของ EAV คือประสิทธิภาพการสืบค้นและแม้จะเป็นเพียงปัญหาเมื่อข้อความค้นหาของคุณเกี่ยวข้องกับ "สิ่ง" (ผลิตภัณฑ์) หลายรายการที่มีคุณลักษณะ ประสิทธิภาพของข้อความค้นหา "ให้แอตทริบิวต์ทั้งหมดสำหรับผลิตภัณฑ์ที่มี id 234" ในขณะที่ไม่เหมาะสมก็ยังเร็วอยู่มาก

วิธีแก้ปัญหาอย่างหนึ่งคือการใช้ฐานข้อมูล SQL / โมเดล EAV สำหรับด้านผู้ดูแลระบบ / แก้ไขของแค็ตตาล็อกผลิตภัณฑ์เท่านั้นและมีกระบวนการบางอย่างที่ทำให้ผลิตภัณฑ์กลายเป็นสิ่งที่ทำให้ค้นหาได้ เนื่องจากคุณมีแอตทริบิวต์อยู่แล้วและด้วยเหตุนี้จึงค่อนข้างเป็นไปได้ว่าคุณต้องการ faceting สิ่งนี้อาจเป็น Solr หรือ ElasticSearch วิธีนี้จะหลีกเลี่ยงข้อเสียทั้งหมดของโมเดล EAV และความซับซ้อนที่เพิ่มเข้ามานั้น จำกัด อยู่ที่การจัดลำดับผลิตภัณฑ์ที่สมบูรณ์เป็น JSON ในการอัปเดต

EAV มีข้อบกพร่องหลายประการ:

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

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

ฉันทำการทดสอบชุดเล็ก ๆเพื่อเปรียบเทียบการออกแบบสองแบบ: แบบหนึ่งใช้ EAV และอีกแบบใช้ Postgres ARRAY เพื่อจัดเก็บข้อมูลเซลล์

EAV

อาร์เรย์

สคีมาทั้งสองมีดัชนีในคอลัมน์ที่เหมาะสมและผู้วางแผนจะใช้ดัชนี

ปรากฎว่าสคีมาที่ใช้อาร์เรย์เป็นลำดับความสำคัญที่เร็วกว่าสำหรับทั้งส่วนแทรกและข้อความค้นหา จากการทดสอบอย่างรวดเร็วดูเหมือนว่าทั้งคู่จะปรับขนาดเป็นเส้นตรง แม้ว่าการทดสอบจะไม่ละเอียดถี่ถ้วนนัก คำแนะนำและส้อมยินดีต้อนรับ - อยู่ภายใต้ใบอนุญาตของ MIT