ตามที่เห็นคุณสามารถแก้ปัญหานี้ได้สองวิธี:
หมวดหมู่เป็นผลิตภัณฑ์ชนิดพิเศษ
ซึ่งหมายความว่าสำหรับผลิตภัณฑ์ใดก็ตามที่ระบุในฐานข้อมูลของคุณประกอบด้วยคีย์ต่างประเทศที่ชี้ไปยังผลิตภัณฑ์ตารางเดียวกัน ผลิตภัณฑ์เป็นผลิตภัณฑ์เฉพาะในกรณีที่ไม่มีผลิตภัณฑ์ที่มีรหัสต่างประเทศเท่ากับรหัสของผลิตภัณฑ์ดังกล่าว กล่าวอีกนัยหนึ่งถ้าไม่มีผลิตภัณฑ์ภายใต้มันเป็นผลิตภัณฑ์
สิ่งนี้จะลดความซับซ้อนของสิ่งเล็กน้อย ผลิตภัณฑ์ต่อคุณสมบัติจะมีความสัมพันธ์แบบหนึ่ง - ต่อ - กลุ่มและหมวดหมู่ของคุณมีความสัมพันธ์แบบหนึ่งต่อหลายเนื่องจากเป็นผลิตภัณฑ์ การเพิ่มพร็อพเพอร์ตี้ในหมวดหมู่นั้นง่ายเหมือนการเพิ่มพร็อพเพอร์ตี้ในผลิตภัณฑ์ของคุณ การโหลดคุณสมบัติทั้งหมดจะหมายถึงการรวมคุณสมบัติของผลิตภัณฑ์เข้ากับคุณสมบัติของผลิตภัณฑ์หมวดหมู่ที่เกี่ยวข้องและขึ้นไปจนกว่าคุณจะไปถึงผลิตภัณฑ์ประเภทที่ไม่มีพาเรนต์
แอปพลิเคชันอีคอมเมิร์ซของคุณจำเป็นต้องแยกความแตกต่างนี้ แต่ถ้าคุณมีแนวโน้มที่จะโหลดผลิตภัณฑ์ในหมวดหมู่ต่อไปจะไม่เป็นการสูญเสียประสิทธิภาพหากคุณรู้ว่าคุณกำลังจัดการกับหมวดหมู่หรือผลิตภัณฑ์ นอกจากนี้ยังให้ยืมตัวเองอย่างดีในการค้นหาแบบต้นไม้ในระดับผลิตภัณฑ์เนื่องจากแต่ละผลิตภัณฑ์ (หมวดหมู่) จะเปิดรายการย่อยของผลิตภัณฑ์โดยไม่ต้องทำงานเพิ่มเติมมากนัก
ข้อเสียของหลักสูตรนี้คือข้อมูลเพิ่มเติมที่นำเสนอในผลิตภัณฑ์ที่ไม่สมเหตุสมผลสำหรับหมวดหมู่จะสร้างเขตข้อมูลที่ไม่ได้ใช้ที่น่าอึดอัดใจในผลิตภัณฑ์ แม้ว่าโซลูชันนี้จะมีความยืดหยุ่นมากขึ้นในแอปพลิเคชันของคุณ แต่ก็ค่อนข้างง่าย
ความสัมพันธ์หลายต่อหลายคน
ผลิตภัณฑ์ไม่ได้อยู่ในความสัมพันธ์แบบรวมกับทรัพย์สินอีกต่อไป คุณสร้างตาราง ProductProperty ด้วย foreign key ของทั้งตารางผลิตภัณฑ์และตารางคุณสมบัติที่เชื่อมโยงทั้งสอง ในทำนองเดียวกันคุณมีตารางหมวดหมู่ที่มีความสัมพันธ์แบบกลุ่มต่อกลุ่มกับตารางคุณสมบัติและตาราง CategoryProperty พร้อมกับคีย์ต่างประเทศของทั้งตารางหมวดหมู่และตารางคุณสมบัติ
ผลิตภัณฑ์จะมีความสัมพันธ์แบบตัวต่อตัวกับหมวดหมู่ช่วยให้คุณสามารถสร้างรายการคุณสมบัติที่เป็นเอกลักษณ์ที่เกี่ยวข้องกับทั้งผลิตภัณฑ์และหมวดหมู่ผ่านคำสั่ง Select ที่เป็นทางการ
จากมุมมองของฐานข้อมูลนี้แน่นอนสะอาดและยืดหยุ่นมากขึ้น แอปพลิเคชันของคุณอาจทำส่วนใหญ่ได้โดยไม่ต้องติดต่อกับ CategoryProperty หรือ ProductProperty โดยตรงหากทำแบบสอบถามอย่างถูกต้อง อย่างไรก็ตามคุณไม่ควรปฏิบัติต่อหมวดหมู่หรือผลิตภัณฑ์ในฐานะเจ้าของทรัพย์สิน มันควรจะเป็นนิติบุคคลของตัวเองในโปรแกรมของคุณ นอกจากนี้ยังหมายถึงการจัดการคุณสมบัติดังกล่าวจะเป็นเรื่องของการสร้างคุณสมบัตินั้นเองจากนั้นเชื่อมโยงกับหมวดหมู่หรือผลิตภัณฑ์ในสองขั้นตอนแยกกัน ทำงานได้มากกว่าโซลูชั่นแรกอย่างแน่นอน แต่ไม่ยากเลย
นอกจากนี้คุณยังจะต้องทำการตรวจสอบเพิ่มเติมเกี่ยวกับการลบหมวดหมู่หรือผลิตภัณฑ์หากมีการใช้คุณสมบัติใด ๆ ของผู้อื่น (ไม่เหมือนโซลูชันแรกที่คุณสามารถกำจัดคุณสมบัติที่เกี่ยวข้องทั้งหมดของผลิตภัณฑ์ / หมวดหมู่ที่กำหนดได้อย่างปลอดภัย) .
ข้อสรุป
ในบริบทมืออาชีพฉันจะไปที่ประเภทไมล์และระยะทางพิเศษจากผลิตภัณฑ์และผลิตภัณฑ์จากอสังหาริมทรัพย์โดยใช้วิธีการแบบกลุ่มต่อกลุ่ม จะไม่มีความเป็นไปได้ที่จะทับซ้อนข้อมูลและในแง่หนึ่งมันง่ายกว่าที่จะให้เหตุผลว่าทั้งสามข้อนี้เป็นเอนทิตีของตัวเอง อย่างไรก็ตามไม่มีทางแก้ปัญหาแรกคือโซลูชันที่ไม่ดีเนื่องจากยังช่วยให้คุณสามารถเขียนแอปพลิเคชันที่เรียบง่ายขึ้น เพิ่งรู้ว่าถ้าคุณคิดว่าคุณอาจจำเป็นต้องเปลี่ยนจากโซลูชันหนึ่งเป็นโซลูชันอื่นในที่สุดก็อาจเป็นผลประโยชน์ที่ดีที่สุดของคุณในการเลือกอันดับที่สอง
โชคดี!
