डेटाबेस डिजाइन:विभिन्न विशेषताओं वाली वस्तुएं

यह टेबल प्रतिबाधा बेमेल संबंध के लिए एक क्लासिक ओओ डिज़ाइन है। आपके द्वारा वर्णित तालिका डिज़ाइन को 'तालिका प्रति उपवर्ग' के रूप में जाना जाता है। आपके ऐप में वास्तव में आपकी वस्तुएं कैसी दिखती हैं, इसकी तुलना में तीन सबसे आम डिज़ाइन सभी समझौता हैं:

प्रति ठोस वर्ग तालिका
प्रति पदानुक्रम तालिका
प्रति उपवर्ग तालिका

आपको जो डिज़ाइन पसंद नहीं है - "जहां टेबल में 100 कॉलम होते हैं और अधिकांश मान NULL होते हैं" - 2 है। संपूर्ण विशेषज्ञता पदानुक्रम को संग्रहीत करने के लिए एक तालिका। यह सभी प्रकार के कारणों से कम से कम लचीला है, जिसमें शामिल हैं - यदि आपके ऐप को एक नए उप-वर्ग की आवश्यकता है, तो आपको कॉलम जोड़ने की आवश्यकता है। आप जिस डिज़ाइन का वर्णन करते हैं वह बदलाव को बेहतर ढंग से समायोजित करता है क्योंकि आप product_type में किसी मान द्वारा वर्णित एक नई उप-वर्ग तालिका जोड़कर इसे बढ़ा सकते हैं।

शेष विकल्प - 1. प्रति ठोस वर्ग तालिका - प्रत्येक विशेषज्ञता तालिका में सभी सामान्य क्षेत्रों को लागू करने में शामिल दोहराव के कारण आमतौर पर अवांछनीय है। हालांकि, लाभ यह है कि आपको किसी भी जॉइन करने की आवश्यकता नहीं है और सब-क्लास टेबल बहुत बड़े सिस्टम में अलग-अलग डीबी इंस्टेंस पर भी हो सकते हैं।

आपके द्वारा वर्णित डिज़ाइन पूरी तरह से व्यवहार्य है। नीचे दी गई भिन्नता यह है कि यदि आप अपने सीआरयूडी संचालन करने के लिए ओआरएम उपकरण का उपयोग कर रहे थे तो यह कैसा दिख सकता है। ध्यान दें कि कैसे प्रत्येक उप-वर्ग तालिका में आईडी पदानुक्रम में मूल तालिका के लिए FK मान है। एक अच्छा ORM स्वतः ही product.id और product.product_type_id में विवेचक मानों के मान के आधार पर सही उप-वर्ग तालिका CRUD का प्रबंधन करेगा। आप ओआरएम का उपयोग करने की योजना बना रहे हैं या नहीं, हाइबरनेट के शामिल उप-वर्ग दस्तावेज़ीकरण को देखें, यदि केवल उनके द्वारा किए गए डिज़ाइन निर्णयों को देखने के लिए।

product
=======

id INT
product_name VARCHAR
product_type_id INT -> Foreign key to product_type.product_type_id
valid_since DATETIME
valid_to DATETIME

magazine
========

id INT -> Foreign key to product.product_id
title VARCHAR
..

web_site
========

id INT -> Foreign key to product.product_id INT
name VARCHAR
..