आपके पास वर्णन करने वाले पदानुक्रम के मॉडलिंग के लिए कम से कम ये पाँच विकल्प हैं:
सिंगल टेबल इनहेरिटेंस : सभी प्रकार की सभी विशेषताओं को संग्रहीत करने के लिए पर्याप्त कॉलम के साथ सभी प्रकार के उत्पाद के लिए एक टेबल। इसका अर्थ बहुत सारे कॉलम हैं, जिनमें से अधिकांश किसी भी पंक्ति में NULL हैं।
क्लास टेबल इनहेरिटेंस : उत्पाद के लिए एक तालिका, सभी उत्पाद प्रकारों के लिए सामान्य विशेषताओं को संग्रहीत करती है। फिर प्रति उत्पाद प्रकार की एक तालिका, उस उत्पाद प्रकार के लिए विशिष्ट विशेषताओं को संग्रहीत करती है।
कंक्रीट टेबल इनहेरिटेंस : आम उत्पाद विशेषताओं के लिए कोई तालिका नहीं। इसके बजाय, प्रति उत्पाद प्रकार एक तालिका, दोनों सामान्य उत्पाद विशेषताओं और उत्पाद-विशिष्ट विशेषताओं को संग्रहीत करते हैं।
सीरियलाइज्ड LOB : प्रोडक्ट्स के लिए एक टेबल, सभी उत्पाद प्रकारों के लिए सामान्य विशेषताओं को संग्रहीत करता है। एक अतिरिक्त स्तंभ XML, YAML, JSON, या कुछ अन्य प्रारूप में एक संरचित डेटा का BLOB संग्रहीत करता है। यह BLOB आपको प्रत्येक उत्पाद प्रकार के लिए विशिष्ट विशेषताओं को संग्रहीत करने की अनुमति देता है। आप इसका वर्णन करने के लिए फैंसी डिज़ाइन पैटर्न का उपयोग कर सकते हैं, जैसे कि फसाडे और मेमेंटो। लेकिन परवाह किए बिना आपके पास ऐसी विशेषताओं का एक समूह है, जिन्हें आसानी से SQL के भीतर नहीं दिखाया जा सकता है; आपको पूरी तरह से ब्लॉब को एप्लिकेशन पर वापस लाना होगा और उसे वहां से सुलझाना होगा।
इकाई-गुण-मूल्य : उत्पादों के लिए एक तालिका, और एक तालिका जिसमें पिवोट्स स्तंभों के बजाय पंक्तियों को दर्शाते हैं। EAV संबंधपरक प्रतिमान के संबंध में एक वैध डिजाइन नहीं है, लेकिन कई लोग इसे वैसे भी उपयोग करते हैं। यह एक अन्य उत्तर द्वारा उल्लिखित "गुण पैटर्न" है। कुछ नुकसान के लिए StackOverflow पर ईआरवी टैग के साथ अन्य प्रश्न देखें ।
मैंने एक प्रस्तुति में इसके बारे में अधिक लिखा है, एक्सटेंसिबल डेटा मॉडलिंग ।
ईएवी के बारे में अतिरिक्त विचार: हालांकि कई लोग ईएवी के पक्ष में लगते हैं, मैं नहीं। यह सबसे लचीला समाधान की तरह लगता है, और इसलिए सबसे अच्छा है। हालांकि, ध्यान TANSTAAFL ध्यान रखें । यहाँ EAV के कुछ नुकसान हैं:
- किसी कॉलम को अनिवार्य (समकक्ष
NOT NULL) बनाने का कोई तरीका नहीं ।
- प्रविष्टियों को मान्य करने के लिए SQL डेटा प्रकारों का उपयोग करने का कोई तरीका नहीं है।
- यह सुनिश्चित करने का कोई तरीका नहीं है कि विशेषता नाम लगातार वर्तनी हैं।
- लुकअप टेबल के लिए किसी दिए गए विशेषता के मूल्यों पर एक विदेशी कुंजी लगाने का कोई तरीका नहीं है।
- एक पारंपरिक सारणीबद्ध लेआउट में परिणाम प्राप्त करना जटिल और महंगा है, क्योंकि
JOINप्रत्येक विशेषता के लिए आपको कई पंक्तियों से विशेषताएँ प्राप्त करने की आवश्यकता होती है ।
लचीलेपन की डिग्री ईएवी आपको अन्य क्षेत्रों में बलिदान की आवश्यकता होती है, संभवतः आपके कोड को जटिल (या इससे भी बदतर) बना देता है, जो मूल समस्या को अधिक पारंपरिक तरीके से हल करने के लिए होता है।
और ज्यादातर मामलों में, लचीलेपन की उस डिग्री का होना अनावश्यक है। उत्पाद प्रकारों के बारे में ओपी के प्रश्न में, उत्पाद-विशिष्ट विशेषताओं के लिए प्रति उत्पाद प्रकार एक तालिका बनाना बहुत सरल है, इसलिए आपके पास उसी उत्पाद प्रकार की प्रविष्टियों के लिए कम से कम कुछ संगत संरचना है।
मैं ईएवी का उपयोग केवल तभी करूँगा जब प्रत्येक पंक्ति को संभावित रूप से विशेषताओं का एक अलग सेट करने की अनुमति होनी चाहिए। जब आपके पास उत्पाद प्रकारों का एक सीमित सेट होता है, तो ईएवी ओवरकिल होता है। क्लास टेबल इनहेरिटेंस मेरी पहली पसंद होगी।
अपडेट 2019: जितना अधिक मैं JSON का उपयोग "कई कस्टम विशेषताओं" समस्या के समाधान के रूप में कर रहा हूं, उतना ही कम मुझे वह समाधान पसंद है। यह विशेष JSON फ़ंक्शंस का उपयोग करते हुए भी प्रश्नों को बहुत जटिल बनाता है। JSON दस्तावेज़ों को संग्रहीत करने के लिए, सामान्य पंक्तियों और स्तंभों में संग्रहीत करने के लिए यह बहुत अधिक संग्रहण स्थान लेता है।
मूल रूप से, इनमें से कोई भी समाधान संबंधपरक डेटाबेस में आसान या कुशल नहीं है। "चर विशेषताएँ" होने का पूरा विचार मौलिक रूप से संबंधपरक सिद्धांत के साथ बाधाओं पर है।
यह नीचे आता है कि आपको उन समाधानों में से एक का चयन करना होगा जिसके आधार पर आपके ऐप के लिए कम से कम खराब हो । इसलिए आपको यह जानना होगा कि डेटाबेस डिज़ाइन चुनने से पहले आप डेटा की क्वेरी कैसे कर रहे हैं। एक समाधान चुनने का कोई तरीका नहीं है जो "सर्वश्रेष्ठ" है क्योंकि किसी भी समाधान किसी दिए गए आवेदन के लिए सबसे अच्छा हो सकता है।