Supertype / Subtype ตัดสินใจเลือกระหว่างหมวดหมู่: ทำไม่ต่อเนื่องหรือทับซ้อนกันไม่สมบูรณ์

ฉันกำลังสร้างฐานข้อมูลสินค้าคงคลังที่เก็บฮาร์ดแวร์ไอทีเช่นคอมพิวเตอร์เดสก์ท็อปแล็ปท็อปสวิตช์เราเตอร์โทรศัพท์มือถือ ฯลฯ ฉันใช้รูปแบบ supertype / subtype ที่เก็บอุปกรณ์ทั้งหมดไว้ในตารางเดียวและข้อมูลเฉพาะ ใส่ลงในตารางย่อย กระอักกระอ่วนของฉันคือการเลือกระหว่างสองแบบต่อไปนี้:

ในแผนภาพด้านบนอุปกรณ์ทั้งหมดแบ่งปันชนิดย่อยทั่วไป ตัวอย่างเช่นคอมพิวเตอร์เดสก์ท็อปและแล็ปท็อปจะมีระเบียนในตารางต่อไปนี้: อุปกรณ์, NetworkDevice สวิตช์จะมีระเบียนเป็น: อุปกรณ์, NetworkDevice เราเตอร์จะมีระเบียนใน: อุปกรณ์, NetworkDevice, WANDevice อุปกรณ์ใด ๆ ที่เราติดตามตำแหน่งจะมีการบันทึกในตำแหน่ง ข้อดีและข้อเสียบางประการที่ฉันคิดไว้สำหรับการตั้งค่านี้:

• Pro: การเลือกระเบียนตามเขตข้อมูลทั่วไปเช่นชื่อโฮสต์หรือ LocationID นั้นง่ายกว่า
• Pro: ไม่มีช่องว่าง
• คอนดิชั่น: ตารางที่ควรรวมอยู่ในการดำเนินการ CRUD สำหรับอุปกรณ์เฉพาะนั้นไม่ชัดเจนและอาจสร้างความสับสนใน DBAs ในอนาคต

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

• Pro: เป็นที่ชัดเจนทันทีว่าตารางใดที่จะใช้สำหรับการดำเนินการ CRUD สำหรับชนิดย่อย
• Pro: ต้องใช้เพียงหนึ่งตารางสำหรับการดำเนินการ CRUD
• คอนดิชั่น: การเลือกเร็กคอร์ดที่อิงตามฟิลด์ย่อยทั่วไปจำเป็นต้องรวมตารางทั้งหมด, เช่นค้นหาตามชื่อโฮสต์, หรือ LocationID.

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

มีคำแนะนำใด ๆ สำหรับการออกแบบที่ดีกว่าหรือเป็นเรื่องของความคิดเห็นอย่างสมบูรณ์และขึ้นอยู่กับจุดประสงค์ของฐานข้อมูล

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

ขอขอบคุณล่วงหน้าสำหรับข้อมูลที่ให้ไว้ โปรดถามว่าต้องการข้อมูลเพิ่มเติมใด ๆ

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

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

• หากจำนวนฟิลด์ฐานข้อมูลทั้งหมดข้ามประเภทย่อยนั้นค่อนข้างต่ำ (พูดว่า: น้อยกว่า 100) หรือมี commonality ที่สำคัญระหว่างประเภทย่อยแล้วแยกย่อยประเภทย่อยออกเป็นตารางทางกายภาพที่แยกต่างหากน่าจะมีค่าน้อย มันจะเพิ่มค่าใช้จ่ายที่สำคัญในการรายงานแบบสอบถามและการค้นหา ในกรณีส่วนใหญ่ควรมีตารางเดียวและจัดการประเภทย่อยของคุณภายในแอปพลิเคชัน (อาจเป็นปัญหาของคุณที่ใกล้เคียงที่สุด)

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

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

• หากคุณมีฟิลด์จำนวนมากที่มี commonality น้อยในประเภทย่อยของคุณและมีความต้องการเพียงเล็กน้อยในการสืบค้นข้ามตารางประเภทย่อย (เช่นไม่มีอะไรมากในการรวมด้านนอกแบบหลายทางเข้ากับตารางย่อยของคุณ) จากนั้น sub- ตารางประเภทอาจช่วยในการจัดการคอลัมน์แผ่กิ่งก้านสาขา (ปัญหาของคุณในเวอร์ชันที่ซับซ้อนทางพยาธิวิทยา)

• ตัวแม็พ O / R บางตัวอาจสนับสนุนวิธีการเฉพาะในการจัดการคลาสย่อยเท่านั้น

ในกรณีส่วนใหญ่ตารางย่อยประเภททางกายภาพใน DB schema เป็นวิธีการแก้ปัญหาเล็กน้อยในการค้นหาปัญหาเนื่องจากอาจมีผลข้างเคียงที่ไม่พึงประสงค์

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

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

ฉันคิดว่าคุณจะพบว่าจำนวนประเภทอุปกรณ์จะใหญ่พอที่จะรับประกันรูปแบบ EAV ตามที่กล่าวไว้ในคำตอบอื่น หนังสือ David Hay ที่ฉันอ้างอิงครอบคลุมรูปแบบนี้อย่างมีประสิทธิภาพมาก อย่างไรก็ตามหากจำนวนของประเภทย่อยมีน้อยคุณสามารถกฎของหัวแม่มือสำหรับการตัดสินใจที่จะใช้เฉพาะตารางประเภท super ที่มีคอลัมน์ nullable จำนวนมากเฉพาะตารางประเภทย่อยที่มีคอลัมน์ที่ซ้ำกันหรือทั้งสองอย่าง หากแต่ละประเภทย่อยแตกต่างกันอย่างมากในแอตทริบิวต์ของมันและไม่มีความสัมพันธ์ในระดับซูเปอร์ประเภทคุณอาจไปกับตารางประเภทย่อยเท่านั้น หากตรงข้ามเป็นจริงคุณอาจไปกับตารางแบบ super-type เท่านั้น หากมีการผสมผสานให้ใช้ทั้งสองอย่าง

หมายเหตุสุดท้ายคุณสามารถนำรูปแบบ EAV มาใช้เป็น schema ของตารางพื้นฐานได้ตลอดเวลาจากนั้นสร้างเลเยอร์ abstraction มุมมองที่แสดงข้อมูลให้กับแอปพลิเคชันเป็นตาราง super และ sub type สิ่งนี้ทำให้คุณมีความยืดหยุ่นในเลเยอร์การจัดเก็บ แต่ความสามารถในการเข้าใจที่เลเยอร์มุมมองแอปพลิเคชัน

ผลิตภัณฑ์ไม่ใช่สินค้าคงคลัง สินค้าคงคลังและผลิตภัณฑ์มีความแตกต่าง

ผลิตภัณฑ์เป็นข้อกำหนดเฉพาะของผลิตภัณฑ์ไม่ใช่ของจริง

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

ฉันจะดูหนังสือทรัพยากรแบบจำลองข้อมูลของ Silverston เล่มที่ 1 เขามีสคีมาที่ดีสำหรับความภาคภูมิใจคุณสมบัติการกำหนดราคาสินค้าคงคลัง มันจะช่วยคุณประหยัดเวลาได้มาก

หนึ่งในคำถามที่ฉันถามคือทำไมคุณติดตามคุณสมบัติต่างๆของรายการสินค้าของคุณ? - หรือโดยเฉพาะคุณทำอะไรกับข้อมูลคุณลักษณะนี้

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

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