रिकॉर्ड मेटाडेटा के भंडारण के लिए सर्वोत्तम अभ्यास


10

डेटाबेस में व्यक्तिगत रिकॉर्ड के मेटाडेटा को संग्रहीत करने के लिए सबसे अच्छा अभ्यास क्या है?

मुझे अपने डेटाबेस में कई तालिकाओं के लिए सामान्य मेटा डेटा जैसे निर्माण समय और अंतिम अपडेट का समय संग्रहीत करने की आवश्यकता है। मुझे कुछ अलग उपाय मिले:

  1. तालिकाओं में सीधे मेटा डेटा संग्रहीत करें।

    पेशेवरों:

    • मेटा डेटा सीधे रिकॉर्ड से जुड़ा हुआ है
    • मेटा डेटा को पुनः प्राप्त करने के लिए किसी जॉइन की आवश्यकता नहीं होती है

    विपक्ष:

    • बहुत सारे डुप्लिकेट कॉलम आवश्यक हैं (जब तक कि इनहेरिटेंस का उपयोग नहीं किया जाता है)
    • मेटा डेटा और व्यावसायिक डेटा को अलग नहीं किया जाता है
  2. सही तालिकाओं और रिकॉर्डों से डेटा लिंक करने के लिए एक सामान्य मेटा डेटा तालिका बनाएं और सॉफ्ट विदेशी कुंजियों का उपयोग करें।

    पेशेवरों:

    • स्तंभों का कोई दोहराव नहीं
    • मेटा डेटा को व्यावसायिक डेटा से अलग किया जाता है

    विपक्ष:

    • मेटा डेटा और डेटा के बीच कोई सीधा संबंध (FK का उपयोग नहीं किया जा सकता)
    • जोड़ों को एक अतिरिक्त स्थिति की आवश्यकता होती है
  3. मेटा डेटा की आवश्यकता वाले प्रत्येक टेबल के लिए व्यक्तिगत मेटा डेटा टेबल बनाएं।

    पेशेवरों:

    • मेटा डेटा सीधे रिकॉर्ड से जुड़ा हुआ है
    • मेटा डेटा को व्यावसायिक डेटा से अलग किया जाता है

    विपक्ष:

    • बहुत सारी अतिरिक्त तालिकाओं की आवश्यकता होती है
    • बहुत सारे डुप्लिकेट कॉलम आवश्यक हैं (जब तक कि इनहेरिटेंस का उपयोग नहीं किया जाता है)

क्या यहां मेरे द्वारा उल्लेखित विकल्पों की तुलना में अधिक विकल्प, पेशेवरों या विपक्ष हैं? और इस मेटा डेटा को संग्रहीत करने के लिए सबसे अच्छा अभ्यास क्या है?


हम किस तरह के मेटाडेटा के बारे में बात कर रहे हैं? शायद hstoreया एक JSONकॉलम का उपयोग करने से आपकी समस्या हल हो सकती है?
a_horse_with_no_name

@a_horse_with_no_name - अभी मुझे केवल सृजन समय, अद्यतन समय और सृजन स्रोत की आवश्यकता है। क्षेत्र तय हो गए हैं, इसलिए मुझे भंडारण की तरह की-वैल्यू की आवश्यकता नहीं है। मैं केवल इस बारे में चिंतित हूं कि मुझे डेटा कहां संग्रहीत करना चाहिए।
टिड्डो

1
तब मुझे उन तीन स्तंभों को आधार तालिका में नहीं जोड़ने का कोई कारण नहीं दिखता।
a_horse_with_no_name

जवाबों:


7

जिन स्तंभों के बारे में आप बात कर रहे हैं, वे 20 बाइट्स पर कब्जा करते हैं (यदि पैडिंग के बिना गठबंधन किया गया है):

निर्माण समय, अद्यतन समय और सृजन स्रोत

टाइमस्टैम्प .. 8 बाइट्स
टाइमस्टैम्प .. 8 बाइट्स
पूर्णांक .. 4 बाइट्स

अकेले एक अलग तालिका में एक अलग पंक्ति के लिए टपल हेडर और आइटम पॉइंटर 23 + 1 + 4 = 28 बाइट्स के साथ वास्तविक डेटा के 20 बाइट्स और प्लस 4 बाइट्स के अंत में होगा। प्रति पंक्ति 52 बाइट बनाता है । यहाँ और पढ़ें:

भंडारण के संबंध में आपको कुछ भी हासिल नहीं करना है। प्रदर्शन के संबंध में आप मुश्किल से केवल 16 - 24 बाइट्स प्रति पंक्ति के साथ कुछ भी खो देते हैं।

स्तंभ भी सीधे पंक्ति से संबंधित हैं, इसलिए यह उन्हें एक साथ रखने के लिए समझ में आता है। मैं इसे सभी संबंधित तालिकाओं में ठीक इसी तरह के कॉलम (अंतिम अद्यतन के लिए अलग स्रोत) जोड़ने की आदत बनाता हूं।

TRIGGER ON INSERT OR UPDATEउन्हें चालू रखने के लिए ए लिखना आसान है ।

लंबी कहानी छोटी: आपके विकल्प 1 के लिए एक मजबूत वोट ।

मैं विकल्प 3 के लिए कहां जाऊंगा :
यदि मेटाडेटा अक्सर अद्यतन किया जाता है, जबकि कोर पंक्ति नहीं है। तब UPDATEs को सस्ता बनाने और मुख्य टेबल पर ब्लोट को कम करने के लिए एक अलग 1: 1 टेबल रखने के लिए भुगतान करना पड़ सकता है - या विकल्प 2 पर जाएं।

मैं विकल्प 2 के लिए कहां जाऊंगा :
यदि मेटाडेटा कॉलम का सेट अत्यधिक दोहराव वाला है। आप मुख्य तालिका (तालिकाओं) में मेटाडेटा के सेट पर एक FK कॉलम रख सकते हैं। अपने उदाहरण में तीन छोटे स्तंभों के लिए ज्यादा बचत नहीं करता है।


टेबल इनहेरिटेंस के साथ इसे हल करने के बारे में, क्या टेबल में मेटाडेटा कॉलम्स का उपयोग करने की तुलना में उल्लेखनीय कमियां हैं? हालाँकि, अगर मैं सही ढंग से समझूँ, तो 'मेज की विरासत उत्तराधिकार मानक मानक अनुरूप नहीं है, क्या मैं?
देवी

1
@devrys: इन्हेरिटेंस की पोस्टग्रेज में कुछ सीमाएँ हैं और अधिक महत्वपूर्ण: मैं यह नहीं देखता कि वंशानुक्रम कैसे कुछ अतिरिक्त कॉलमों को अपनी पंक्ति में सहेज कर हल कर सकता है । यह एक विकल्प होगा यदि आपके पास मेटाडेटा के बिना कुछ पंक्तियाँ और अन्य पंक्तियाँ हैं। लेकिन मैं इसके लिए इसका इस्तेमाल नहीं करूंगा ।
इरविन ब्रान्डस्टेट्टर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.