बहुत अधिक कॉलम वाली तालिका के नुकसान

यहाँ कुछ बातों पर ध्यान देना चाहिए:

क्या विशेषताओं की सूची समय के साथ महत्वपूर्ण रूप से बदलती है
क्या विशेषताओं की सूची के लिए कस्टम उपयोगकर्ता-परिभाषित विशेषताओं की आवश्यकता होती है
क्या विभिन्न स्कूलों के लिए अलग-अलग विशेषताएं हैं (यानी कई विशेषताएँ केवल एक या कुछ स्कूलों पर लागू होती हैं)?

यदि इनमें से कोई भी सत्य है, तो आप प्रॉपर्टी स्टोर दृष्टिकोण के बारे में सोच सकते हैं जैसे EAV, hstore, json फ़ील्ड, xml फ़ील्ड, आदि ।

यदि नहीं - यदि आपके पास संपत्तियों की एक काफी स्थिर सूची है जहां उनमें से अधिकतर पंक्तियों के लिए समझ में आता है - तो वास्तव में उन्हें 60 अलग-अलग कॉलम रखने में कोई समस्या नहीं है। आम तौर पर खोजे गए गुणों के सेट के लिए इंडेक्स जोड़ना आसान होगा, जिसमें आंशिक और मिश्रित इंडेक्स आदि शामिल हैं, और खोजों - विशेष रूप से कई अलग-अलग विशेषताओं के लिए - बहुत होंगे तेज़।

यह भी देखें:डेटाबेस डिज़ाइन - क्या मुझे JSON/XML के रूप में सभी डेटा के साथ 30 कॉलम या 1 कॉलम का उपयोग करना चाहिए ?

आपके लिए एक समझौता विकल्प भी उपलब्ध है:सबसे महत्वपूर्ण विवरणों के लिए एक मुख्य तालिका जिसे आप बहुत अधिक देखते हैं, साथ ही विशेषताओं के तार्किक समूहों के लिए साइड-टेबल। कहो:

yearly_summary (
    yearly_summary_id serial primary key,
    school_id integer,
    total_students integer,
    ...
)

प्लस

yearly_student_stats(
    yearly_summary_id integer primary key references yearly_summary(yearly_summy_id) on delete cascade,
    ...
)

आदि integer primary key वह भी एक foreign key है इसका मतलब है कि आपके पास दूसरी तालिका के लिए एक लागू 1:1 (वैकल्पिक) संबंध है। यह दृष्टिकोण उपयोगी हो सकता है यदि आपके पास विशेषताओं के कुछ तार्किक समूह हैं जिन्हें आप साइड-टेबल में क्लस्टर कर सकते हैं।

मुझे भी आश्चर्य होगा अगर थोड़ा और विचार उन चीजों को प्रकट नहीं करता जो करते हैं सामान्य करने के लिए समझ में आता है। क्या आपके पास year7_blah है , year8_blah , year9_blah आदि कॉलम? अगर ऐसा है:सामान्यीकरण के लिए बढ़िया उम्मीदवार।