अपने डेटाबेस का स्ट्रक्चर तैयार करें

इस गाइड में, डेटा आर्किटेक्चर से जुड़े कुछ अहम सिद्धांतों के साथ-साथ, सबसे बेहतर आपके Firebase रीयल टाइम डेटाबेस में JSON डेटा तैयार करने के तरीके.

एक सही तरीके से स्ट्रक्चर किया गया डेटाबेस बनाने के लिए, काफ़ी पहले से सोच-विचार करने की ज़रूरत होती है. सबसे ज़रूरी बात, आपको यह प्लान करना होगा कि डेटा कैसे सेव किया जाएगा और ताकि उस प्रक्रिया को जितना हो सके उतना आसान बनाया जा सके.

डेटा को कैसे व्यवस्थित किया जाता है: यह एक JSON ट्री है

Firebase रीयल टाइम डेटाबेस का पूरा डेटा, JSON ऑब्जेक्ट के तौर पर सेव किया जाता है. आप सोच सकते हैं कि डेटाबेस को क्लाउड पर होस्ट किए गए JSON ट्री के तौर पर सेव करता है. SQL डेटाबेस के उलट, इसमें कोई टेबल या रिकॉर्ड शामिल हैं. JSON ट्री में डेटा जोड़ने पर, यह मौजूदा JSON स्ट्रक्चर को ऐक्सेस करने के लिए किया जा सकता है. अपने पास खुद की कुंजियां दी जा सकती हैं, जैसे कि यूज़र आईडी या सिमैंटिक नाम या वे आपको इनका इस्तेमाल करके दिए जा सकते हैं childByAutoId.

अगर आप अपनी खुद की कुंजियां बनाते हैं, तो वे UTF-8 में एन्कोड की गई होनी चाहिए. ये कुंजियां, ज़्यादा से ज़्यादा हो सकती हैं का साइज़ 768 बाइट है और इसमें ., $, #, [, ], / या ASCII कंट्रोल नहीं हो सकता वर्ण 0-31 या 127. वैल्यू में ASCII कंट्रोल वर्ण इस्तेमाल नहीं किए जा सकते खुद को भी चुन सकते हैं.

उदाहरण के लिए, ऐसे चैट ऐप्लिकेशन पर विचार करें जो उपयोगकर्ताओं को प्रोफ़ाइल और संपर्क सूची. एक सामान्य उपयोगकर्ता प्रोफ़ाइल पाथ पर मौजूद होती है, जैसे /users/$uid. उपयोगकर्ता alovelace के पास ऐसी डेटाबेस एंट्री हो सकती है जो कुछ ऐसा दिखता है:

{
  "users": {
    "alovelace": {
      "name": "Ada Lovelace",
      "contacts": { "ghopper": true },
    },
    "ghopper": { ... },
    "eclarke": { ... }
  }
}

हालांकि डेटाबेस, JSON ट्री का इस्तेमाल करता है, लेकिन डेटाबेस में सेव किया गया डेटा दिखाए गए कुछ खास तरह के नेटिव टाइप, जो उपलब्ध JSON टाइप से मेल खाते हैं ताकि आपको मैनेज किए जा सकने वाले कोड लिखने में मदद मिल सके.

डेटा स्ट्रक्चर के लिए सबसे सही तरीके

डेटा को नेस्ट करने से बचना

Firebase रीयल टाइम डेटाबेस, 32 लेवल तक डेटा को नेस्ट करने की अनुमति देता है. ऐसा हो सकता है कि आप इसके बजाय, डिफ़ॉल्ट स्ट्रक्चर के तौर पर इसे लागू करना चाहें. हालांकि, जब अपने डेटाबेस में किसी जगह पर डेटा फ़ेच किया जाता है, तो आपको यह जानकारी भी मिल जाती है कि इसके सभी चाइल्ड नोड. साथ ही, जब किसी व्यक्ति को कॉन्टेंट पढ़ने या उसमें बदलाव करने का ऐक्सेस दिया जाता है आपके डेटाबेस के किसी नोड में होता है, तो आप उन्हें इसके तहत आने वाले सारे डेटा का ऐक्सेस भी देते हैं नोड के लिए अलग-अलग हैं. इसलिए, बेहतर होगा कि अपने डेटा स्ट्रक्चर को एक जैसा रखें किया जा सकता है.

नेस्ट किया गया डेटा खराब क्यों है, इसके उदाहरण के लिए इन बातों पर ध्यान दें मल्टी-नेस्ट की गई संरचना:

{
  // This is a poorly nested data architecture, because iterating the children
  // of the "chats" node to get a list of conversation titles requires
  // potentially downloading hundreds of megabytes of messages
  "chats": {
    "one": {
      "title": "Historical Tech Pioneers",
      "messages": {
        "m1": { "sender": "ghopper", "message": "Relay malfunction found. Cause: moth." },
        "m2": { ... },
        // a very long list of messages
      }
    },
    "two": { ... }
  }
}

इस नेस्ट किए गए डिज़ाइन के साथ, डेटा के ज़रिए बार-बार काम करने में समस्या आ जाती है. इसके लिए उदाहरण के लिए, चैट बातचीत के टाइटल की सूची बनाने के लिए, पूरे chats की ज़रूरत होती है ट्री, जिसमें सभी सदस्य और मैसेज शामिल हैं, को क्लाइंट पर डाउनलोड करना होगा.

डेटा स्ट्रक्चर को फ़्लैट करें

अगर इसके बजाय डेटा को अलग-अलग पाथ में बांटा जाए, तो इसे डिनॉर्मलाइज़ेशन भी कहा जाता है, ज़रूरत पड़ने पर, इसे अलग-अलग कॉल में बेहतर तरीके से डाउनलोड किया जा सकता है. इन बातों पर ध्यान दें यह समतल संरचना है:

{
  // Chats contains only meta info about each conversation
  // stored under the chats's unique ID
  "chats": {
    "one": {
      "title": "Historical Tech Pioneers",
      "lastMessage": "ghopper: Relay malfunction found. Cause: moth.",
      "timestamp": 1459361875666
    },
    "two": { ... },
    "three": { ... }
  },

  // Conversation members are easily accessible
  // and stored by chat conversation ID
  "members": {
    // we'll talk about indices like this below
    "one": {
      "ghopper": true,
      "alovelace": true,
      "eclarke": true
    },
    "two": { ... },
    "three": { ... }
  },

  // Messages are separate from data we may want to iterate quickly
  // but still easily paginated and queried, and organized by chat
  // conversation ID
  "messages": {
    "one": {
      "m1": {
        "name": "eclarke",
        "message": "The relay seems to be malfunctioning.",
        "timestamp": 1459361875337
      },
      "m2": { ... },
      "m3": { ... }
    },
    "two": { ... },
    "three": { ... }
  }
}

अब चैट रूम की सूची में, सिर्फ़ हर बातचीत की कुछ बाइट, लिस्टिंग या डिसप्ले के लिए तेज़ी से मेटाडेटा फ़ेच किया जा रहा है यूज़र इंटरफ़ेस (यूआई) में रूम. मैसेज अलग से फ़ेच किए जा सकते हैं और उनके आने पर वे दिखते हैं, इसकी मदद से, यूज़र इंटरफ़ेस (यूआई) को रिस्पॉन्सिव और तेज़ बनाया जा सकता है.

स्केल करने वाला डेटा बनाएं

ऐप्लिकेशन बनाते समय, सूची का सबसेट डाउनलोड करना अक्सर बेहतर होता है. ऐसा खास तौर पर तब होता है, जब सूची में हज़ारों रिकॉर्ड हों. जब यह संबंध स्थिर और एकतरफ़ा हो, तो आप चाइल्ड ऑब्जेक्ट से मिलता-जुलता है.

कभी-कभी, यह संबंध ज़्यादा डाइनैमिक होता है या यह ज़रूरी हो सकता है कि इस डेटा को सामान्य न बनाना हो. कई बार आप क्वेरी का इस्तेमाल करके डेटा को डीनॉर्मलाइज़ कर सकते हैं डेटा के किसी सबसेट को फिर से पाने के लिए, जैसा कि डेटा वापस पाएं.

हालांकि, यह भी हो सकता है कि यह काफ़ी न हो. उदाहरण के लिए, दो-तरफ़ा संबंध पर विचार करें उपयोगकर्ता और ग्रुप के बीच. उपयोगकर्ता किसी ग्रुप में शामिल हो सकते हैं और ग्रुप में उपयोगकर्ताओं की सूची. जब यह तय करना होता है कि उपयोगकर्ता किस ग्रुप से जुड़ा है, चीज़ें मुश्किल हो जाती हैं.

हालांकि, सबसे ज़रूरी है कि आप उन ग्रुप की सूची बनाएं जिनसे कोई उपयोगकर्ता जुड़ा है और केवल उन समूहों का डेटा फ़ेच किया जाता है. ग्रुप के इंडेक्स से यहां बहुत अच्छा लगा:

// An index to track Ada's memberships
{
  "users": {
    "alovelace": {
      "name": "Ada Lovelace",
      // Index Ada's groups in her profile
      "groups": {
         // the value here doesn't matter, just that the key exists
         "techpioneers": true,
         "womentechmakers": true
      }
    },
    ...
  },
  "groups": {
    "techpioneers": {
      "name": "Historical Tech Pioneers",
      "members": {
        "alovelace": true,
        "ghopper": true,
        "eclarke": true
      }
    },
    ...
  }
}

आप देख सकते हैं कि यह संबंध जानकारी को संग्रहित करके कुछ डेटा को डुप्लीकेट करता है एडा के रिकॉर्ड में और ग्रुप में. अब alovelace को और techpioneers, Ada की प्रोफ़ाइल में मौजूद है. ऐडा को मिटाने के लिए को ग्रुप से बाहर रखना है, तो इसे दो जगहों पर अपडेट करना होगा.

यह दो-तरफ़ा संबंधों के लिए एक ज़रूरी रिडंडंसी है. इससे आपको ये काम करने में मदद मिलती है की सदस्यता को तुरंत और आसानी से फ़ेच कर सकते हैं. ऐसा तब भी होगा, जब ग्रुप की पहुंच लाखों में या रीयल टाइम डेटाबेस के सुरक्षा नियमों के आधार पर होती है कुछ रिकॉर्ड का ऐक्सेस रोका जाता है.

यह तरीका अपनाकर, आईडी को कुंजियों के तौर पर जोड़कर और मान सही पर सेट करता है, जिससे कुंजी की जांच करना पढ़ने जितना आसान हो जाता है /users/$uid/groups/$group_id और यह जांच रहा है कि null है या नहीं. इंडेक्स ज़्यादा तेज़ है और डेटा को क्वेरी या स्कैन करने की तुलना में ज़्यादा बेहतर तरीके से काम करते हैं.

अगले चरण

• डेटा को अपने रीयलटाइम डेटाबेस में सेव करना
• अपने रीयलटाइम डेटाबेस से डेटा वापस पाना