इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

आपका डेटाबेस संरचना

यह गाइड आपके फायरबेस रियलटाइम डेटाबेस में JSON डेटा की संरचना के लिए डेटा आर्किटेक्चर और सर्वोत्तम प्रथाओं में कुछ प्रमुख अवधारणाओं को शामिल करता है।

एक अच्छी तरह से संरचित डेटाबेस के निर्माण के लिए बहुत थोड़े समय की आवश्यकता होती है। सबसे महत्वपूर्ण बात, आपको यह योजना बनाने की आवश्यकता है कि डेटा को कैसे बचाया जा सकता है और बाद में उस प्रक्रिया को यथासंभव आसान बनाने के लिए पुनर्प्राप्त किया जा सकता है।

डेटा कैसे संरचित है: यह एक JSON ट्री है

सभी फायरबेस रियलटाइम डेटाबेस डेटा को JSON ऑब्जेक्ट्स के रूप में संग्रहीत किया जाता है। आप डेटाबेस को क्लाउड-होस्ट किए गए JSON ट्री के रूप में सोच सकते हैं। SQL डेटाबेस के विपरीत, कोई टेबल या रिकॉर्ड नहीं हैं। जब आप JSON ट्री में डेटा जोड़ते हैं, तो यह एक संबंधित कुंजी के साथ मौजूदा JSON संरचना में एक नोड बन जाता है। आप अपनी स्वयं की चाबियाँ प्रदान कर सकते हैं, जैसे उपयोगकर्ता आईडी या शब्दार्थ नाम, या वे आपके लिए push() का उपयोग करके प्रदान की जा सकती हैं।

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

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

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

यद्यपि डेटाबेस एक JSON ट्री का उपयोग करता है, डेटाबेस में संग्रहीत डेटा को कुछ देशी प्रकारों के रूप में दर्शाया जा सकता है जो आपको अधिक अनुरक्षण कोड लिखने में मदद करने के लिए उपलब्ध JSON प्रकारों के अनुरूप होते हैं।

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

नेस्टिंग डेटा से बचें

क्योंकि Firebase Realtime Database 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
      }
    },
    ...
  }
}

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

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

यह दृष्टिकोण, आईडी को कुंजियों के रूप में सूचीबद्ध करके और सत्य को मान सेट करके डेटा को परिवर्तित करने, कुंजी को पढ़ने /users/$uid/groups/$group_id रूप में सरल बनाने के लिए जाँच करता है और अगर यह null । डेटा को क्वेरी या स्कैन करने की तुलना में इंडेक्स तेज़ और एक अच्छा सौदा है।

अगला कदम