अच्छा डेटाबेस डिज़ाइन, विशेषताओं की चर संख्या

विकल्प 1, 2, और 3 में एक बहुत ही गंभीर खामी है:जब कोई नई विशेषता का सपना देखता है तो आपको अंतर्निहित तालिका स्कीमा को संशोधित करना होगा। विकल्प 1 के मामले में समस्या इस संभावना से जटिल हो जाती है कि एक नया उपकरण प्रकार पेश किया जाएगा। आप कितने आश्वस्त हैं कि विशेषताओं का सेट हमेशा के लिए नियत है? आपको आउटेज लेने या क्लाइंट को यह बताने में कितनी खुशी होगी कि नहीं, आपके पास एक नई विशेषता नहीं हो सकती है?

यदि आप सामान्य विशेषताओं से पूछताछ करने की बहुत संभावना रखते हैं, तो आप उपकरण प्रकार के बजाय विशेषता प्रकार पर विभाजन में फेंके गए 2 के डैश के साथ 3 और 4 के हाइब्रिड का प्रयास कर सकते हैं, जो बहुत अधिक अस्थिर लगता है। विकल्प 4, अगर मैं सही ढंग से समझूं, तो विकल्प 1 का एक सामान्य रूप संस्करण है जो इसकी सभी अंतर्निहित समस्याओं (विरलता और भंगुरता) को हल करता है।

INVENTORY( id*, model, manufacturer, serial )
ATTRIBUTE( id*, name, type, description )
INVENTORY_FACT_STRING( inv_id*, attr_id*, value )
INVENTORY_FACT_NUMBER( inv_id*, attr_id*, value )
INVENTORY_FACT_LIST_STRING( inv_id*, attr_id*, ordinal*, value )

आदि.