गूगल काले समुदायों के लिए जातीय इक्विटी को आगे बढ़ाने के लिए प्रतिबद्ध है। देखो कैसे।
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

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

शुरू करने से पहले

इससे पहले कि आप उपयोग कर सकते हैं रीयलटाइम डाटाबेस , आप की जरूरत है:

  • रजिस्टर अपने एकता परियोजना और इसे कॉन्फ़िगर Firebase उपयोग करने के लिए।

    • अपने एकता परियोजना पहले से ही Firebase का उपयोग करता है, तो यह पहले से ही पंजीकृत और Firebase के लिए कॉन्फ़िगर किया गया है।

    • यदि आप एक एकता परियोजना की जरूरत नहीं है, तो आप एक डाउनलोड कर सकते हैं नमूना एप्लिकेशन

  • जोड़े में Firebase एकता एसडीके (विशेष रूप से, FirebaseDatabase.unitypackage ) अपने एकता परियोजना के लिए।

ध्यान रखें कि आपके एकता परियोजना के लिए Firebase जोड़ने दोनों में कार्य शामिल है Firebase सांत्वना और अपने खुले एकता परियोजना में (उदाहरण के लिए, आप Firebase config फ़ाइलों कंसोल से डाउनलोड, फिर उन्हें अपने एकता परियोजना में ले जाते हैं)।

स्ट्रक्चरिंग डाटा

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

एक ठीक से संरचित डेटाबेस का निर्माण काफी पूर्वविवेक का एक सा की आवश्यकता है। सबसे महत्वपूर्ण बात, आप कैसे डेटा सहेजा जा रहा है और बाद में संभव के रूप में आसान के रूप में है कि इस प्रक्रिया बनाने के लिए लिया गया के लिए योजना की जरूरत है।

डेटा की संरचना कैसी है: यह एक JSON पेड़ है

सभी Firebase रीयलटाइम डेटाबेस डेटा संग्रहीत 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 पेड़ का उपयोग करता है, डेटाबेस में संग्रहीत डेटा है कि मदद करने के लिए आप और अधिक maintainable कोड लिखने उपलब्ध 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": { ... }
  }
}

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

कि तराजू डेटा बनाएं

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

कभी कभी, यह संबंध और अधिक गतिशील है, या यह इस डेटा denormalize करने के लिए आवश्यक हो सकता है। कई बार आप के रूप में में चर्चा की, डेटा के एक उपसमूह पुनः प्राप्त करने के एक प्रश्न का उपयोग करके डेटा denormalize कर सकते हैं डेटा पुनः प्राप्त

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

क्या आवश्यक है समूहों किसी उपयोगकर्ता का है सूची और केवल उन समूहों के लिए डेटा प्राप्त करने का एक सुंदर तरीका है। समूहों में से एक सूचकांक यहाँ एक महान सौदा मदद कर सकते हैं:

// 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 एडीए के प्रोफ़ाइल में सूचीबद्ध है। तो समूह से एडीए को हटाने के लिए, यह दो स्थानों पर अद्यतन किया जाना है।

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

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

अगला कदम