2017-05-07 15 views
7

मैं अपने सिर को लपेटने की कोशिश कर रहा हूं कि फायरबेस रीयलटाइम डेटाबेस के लिए मेरे डेटा को कैसे व्यवस्थित किया जाए।फ़ायरबेस रीयलटाइम डेटाबेस के लिए डेटा संरचना को सामान्य/सामान्य कैसे करें?

  • डेटा संभव के रूप में फ्लैट पर लिखता सस्ते
  • से बचने के घोंसले डेटा
  • से डेटा का डुप्लिकेट पढ़ता है करने के लिए
  • महंगा हो जाना चाहिए: मैं इतना निम्न सलाह खोजने पर docs और कुछ अन्य सवालों को पढ़ने ठीक हो सकता है

इसे ध्यान में रखते हुए मुझे अपने विशिष्ट उपयोग मामले का वर्णन करने दें। ,

  • प्रथम
  • अंतिम नाम
  • प्रोफ़ाइल चित्र (बड़ा)
  • प्रोफ़ाइल चित्र (छोटे)

एक उपयोगकर्ता एक कहानी बना सकते हैं: Frist निम्न विशेषताओं वाला उपयोगकर्ता है जिसमें निम्नलिखित विशेषताएं शामिल हैं:

  • उपयोगकर्ता
  • पाठ
  • टाइमस्टैम्प

एक कहानी के दृश्य प्रतिनिधित्व कुछ ऐसा दिखाई देगा:

enter image description here

मेरा प्रश्न है, आप कैसे सहयोगी उपयोगकर्ता जानकारी (firstname होगा , आखिरी नाम, छोटी प्रोफ़ाइल तस्वीर) एक कहानी के साथ?

क्या मैं के बारे में सोचा:

  1. कहानी है कि विशिष्ट उपयोगकर्ता के लिए विदेशी आईडी में शामिल है में एक user_id डाल दिया। कहानी को लोड करने के लिए हमें डेटाबेस के लिए दो अनुरोध करना होगा, एक कहानी प्राप्त करने के लिए और उपयोगकर्ता के लिए एक।

    { user_id: 'XYZ', पाठ: 'foobar', टाइमस्टैम्प: ... }

  2. डाल firstname, कहानी में उपनाम और छोटे प्रोफ़ाइल तस्वीर। कहानी प्रदर्शित करने के लिए केवल एक अनुरोध आवश्यक होगा। लेकिन हमें प्रत्येक उपयोगकर्ता की कहानी अपडेट करना होगा, जब उदा। प्रोफ़ाइल तस्वीर बदलती है।

    { user_id: 'XYZ', firstname: 'सैंड्रा', lastname: '' एडम्स, smallProfilePicutre: '...', पाठ: 'foobar', टाइमस्टैम्प: ... }

तो जब वहाँ कुछ बनाया कहानियाँ हैं और ज्यादातर समय वहाँ सिर्फ पढ़ता है, दृष्टिकोण 1. महंगा हो सकता है, क्योंकि हम दो के लिए भुगतान एक कहानी प्रदर्शित करने के लिए पढ़ता है। दृष्टिकोण 2. अधिक लागत प्रभावी होगा।

मैं यहां इस पर आपके विचार और विचारों को देखना चाहता हूं।

+4

मुझे लगता है कि आपको बहुत कुछ है। दो विकल्प, कहानी में उपयोगकर्ता के लिए एक संदर्भ स्टोर, उपयोगकर्ता जानकारी प्राप्त करने के लिए फायरबेस के लिए दो कॉल। या, कहानी में डुप्लिकेट उपयोगकर्ता डेटा स्टोर करें, 1 कॉल यह सब करता है। हालांकि, विकल्प 2 के साथ डेटा को बनाए रखना बहुत कठिन है। मान लीजिए कि उपयोगकर्ता अपनी तस्वीर बदलता है, आपको उन सभी कहानियों के लिए पूछना होगा जहां उन्हें दिखाई देता है और उन्हें अपडेट किया जाता है। एक 'छोटे' डेटासेट के लिए जो ठीक है, एक बड़े डेटासेट के लिए यह अनावश्यक हो सकता है। फायरबेस बहुत तेज है इसलिए विकल्प 1 शायद इस उपयोग के मामले में जाने का सबसे अच्छा तरीका है। आपको वास्तव में कुछ कोड लिखना चाहिए और दोनों मामलों को आजमाएं। – Jay

+0

महान टिप्पणी जय! इसे एक उत्तर के रूप में पोस्ट करने जैसा लगता है, तो मैं इसे ऊपर उठा सकता हूं? :-) –

+2

मैंने इस उद्देश्य के लिए फायरबेस क्लाउड फ़ंक्शंस के साथ खिलवाड़ किया है। आप normalizeUserProfile_Stories() नामक एक फ़ंक्शन बना सकते हैं जो उपयोगकर्ता प्रोफ़ाइल में परिवर्तनों को देखता है और कहानियों नोड के अंतर्गत उन विशेषताओं को अपडेट करता है। फिर आप क्लाइंट साइड से डेटाबेस में कई नोड्स को लिखने के बारे में चिंता किए बिना अपना एकल पढ़ सकते हैं। मुझे लगता है कि क्लाउड फ़ंक्शंस डेटा अखंडता को बनाए रखने और इस तरह के कार्य को ऐप से ही हटाने के लिए अच्छा है। – Shai

उत्तर

8

मैं यहां जय के साथ हूं: आप इसे पहले से ही अपने प्रश्न में बहुत कुछ मिला है। फायरबेस डेटाबेस का उपयोग करते समय हम सुझाए गए अभ्यासों का महान सारांश।

आपके प्रश्न नीचे उबलते हैं: क्या मुझे अपनी उपयोगकर्ता प्रोफ़ाइल जानकारी को प्रत्येक कहानी में डुप्लिकेट करना चाहिए? दुर्भाग्यवश इसके लिए कोई जवाब नहीं है।

अधिकांश डेवलपर्स जो मैं देखता हूं वे प्रोफाइल जानकारी को अलग रखेंगे और केवल यूआईडी को पोस्ट में अप्रबंधित विदेशी कुंजी के रूप में रखेंगे। जब उपयोगकर्ता बदलता है तो उपयोगकर्ता प्रोफ़ाइल को केवल एक ही स्थान में अपडेट करने की आवश्यकता का लाभ होता है। एक कहानी पढ़ने के लिए प्रदर्शन बहुत खराब नहीं है: दो पढ़ना अपेक्षाकृत तेज़ हैं, क्योंकि वे एक ही कनेक्शन पर जाते हैं। जब आप कहानियों की एक सूची दिखा रहे हैं, तो यह Firebase pipelines the requests over its single connection के बाद अप्रत्याशित रूप से तेज़ है।

लेकिन पहले बड़े कार्यान्वयन में से एक ने वास्तव में कहानियों पर उपयोगकर्ता डेटा को डुप्लिकेट करने में मदद की। जैसा कि आपने कहा था: कहानियों की कहानी या सूची पढ़ना उतना तेज़ है जितना कि उस मामले में हो सकता है। जब उनसे पूछा गया कि उन्होंने कहानियों में उपयोगकर्ता की जानकारी को अद्यतित रखने के साथ कैसे व्यवहार किया है (रणनीतियों here देखें), उन्होंने स्वीकार किया कि उन्होंने नहीं किया। वास्तव में: उन्होंने कई अच्छे कारणों से तर्क दिया कि उन्हें प्रत्येक कहानी के लिए ऐतिहासिक उपयोगकर्ता जानकारी की आवश्यकता क्यों है।

अंत में, यह सब आपके उपयोग-मामले पर निर्भर करता है। आपको सवालों के जवाब देने की आवश्यकता होगी जैसे:

  • क्या आपको प्रत्येक उपयोगकर्ता के लिए ऐतिहासिक जानकारी की आवश्यकता है?
  • क्या यह महत्वपूर्ण है कि आप पुराने पदों में किसी उपयोगकर्ता के लिए अद्यतित जानकारी दिखाएं?
  • क्या आप अपने क्लाइंट-साइड कोड में उपयोगकर्ता प्रोफाइल के लिए एक अच्छी कैशिंग रणनीति के साथ आ सकते हैं?
+0

को बनाए रखने के लिए कठिन हो सकता है, महान उत्तर और रोचक डेवलपर कहानी, धन्यवाद फ्रैंक !! –

संबंधित मुद्दे