खोज…


परिचय

Firebase डेटाबेस एक NoSQL डेटाबेस है जो अपने डेटा को hierarchal JSON ऑब्जेक्ट्स के रूप में संग्रहीत करता है। किसी भी रूप में कोई तालिका या रिकॉर्ड नहीं हैं क्योंकि एसक्यूएल डेटाबेस में सामान्य रूप से होगा, बस नोड्स जो एक कुंजी-मूल्य संरचना बनाते हैं।

डेटा सामान्यीकरण

ठीक से डिज़ाइन किया गया डेटाबेस संरचना करने के लिए, डेटा आवश्यकताओं को पूरी तरह से रेखांकित किया जाना चाहिए और पूर्वविचारित किया जाना चाहिए। इस मामले में संरचना को सामान्यीकृत किया जाना चाहिए; JSON पेड़ जितना अधिक सपाट होगा, डेटा-एक्सेस उतना ही तेज़ होगा।

क्या करें और क्या नहीं

गलत रास्ता

निम्नलिखित संरचना पर विचार करें

{
  "users": {

    // Uniquely generated IDs for children is common practice,
    // it's actually really useful for automating child creation.
    // Auto-incrementing an integer for a key can be problematic when a child is removed.

    "-KH3Cx0KFvSQELIYZezv": {     
      "name": "Jon Snow",
      "aboutMe": "I know nothing...",
      "posts": {
        "post1": { 
          "body": "Different roads sometimes leads to the same castle", 
          "isHidden": false
        },
        "post2": { ... },
        // Possibly more posts
      }
    },
    "-KH3Dx2KFdSLErIYZcgk": { ... },     // Another user
    // A lot more users here
  }
}

यह एक महान उदाहरण है कि क्या नहीं करना है। मल्टी-नेस्टेड संरचनाएं जैसे ऊपर वाला बहुत समस्याग्रस्त हो सकता है और एक बड़ा प्रदर्शन झटका पैदा कर सकता है।

जिस तरह से Firebase एक नोड का उपयोग करता है, वह सभी बच्चों के डेटा को डाउनलोड करने के बाद होता है, फिर सभी समान-स्तर के नोड्स (सभी माता-पिता के बच्चों) पर पुनरावृत्ति करता है। अब, कई उपयोगकर्ताओं के साथ एक डेटाबेस की कल्पना करें, प्रत्येक में सैकड़ों (या हजारों भी) पद हैं । इस मामले में एक पोस्ट तक पहुँचने से अप्रयुक्त डेटा के सैकड़ों मेगाबाइट लोड हो सकते हैं। एक अधिक जटिल अनुप्रयोग में, घोंसला सिर्फ 4 परतों से अधिक गहरा हो सकता है, जिसके परिणामस्वरूप अधिक बेकार डाउनलोड और पुनरावृत्तियों होंगे।

सही तरीका

समान संरचना को समतल करना इस तरह दिखेगा

{
  // "users" should not contain any of the posts' data
  "users": {
    "-KH3Cx0KFvSQELIYZezv": {
      "name": "Jon Snow",
      "aboutMe": "I know nothing..."
    },
    "-KH3Dx2KFdSLErIYZcgk": { ... },
    // More users
  },

  // Posts can be accessed provided a user key
  "posts": {
    "-KH3Cx0KFvSQELIYZezv": {     // Jon Snow's posts
      "post1": { 
        "body": "Different roads sometimes leads to the same castle", 
        "isHidden": false
      },
      "post2": { ... },
      // Possibly more posts
    },
    "-KH3Dx2KFdSLErIYZcgk": { ... },
    // other users' posts
  }
}

यह लक्ष्य वस्तु तक पहुँचने के लिए कम नोड्स पर पुनरावृति करके उपरि की एक बड़ी मात्रा को बख्शता है। सभी उपयोगकर्ता जिनके पास कोई भी पोस्ट नहीं है, वे पोस्ट ब्रांच में मौजूद नहीं होंगे, और इसलिए उन उपयोगकर्ताओं के ऊपर गलत तरीके से चलना पूरी तरह से बेकार है।

टू-वे रिलेशनशिप

निम्नलिखित एक सरल और न्यूनतम कॉलेज डेटाबेस का एक उदाहरण है जो दो-तरफ़ा रिश्तों का उपयोग करता है

{
  "students": {
    "-SL3Cs0KFvDMQLIYZEzv": {
      "name": "Godric Gryffindor",
      "id": "900130309",
      "courses": {
         "potions": true,
         "charms": true,
         "transfiguration": true, 
      }
    },
    "-SL3ws2KvZQLTYMqzSas": {          
      "name": "Salazar Slytherin",
      "id": "900132319",
      "courses": {
         "potions": true,
         "herbs": true,
         "muggleStudies": true, 
      }
    },
    "-SL3ns2OtARSTUMywqWt": { ... },
    // More students here
  },

  "courses": {
    "potions": {
      "code": "CHEM305",
      "enrolledStudents": {
        "-SL3Cs0KFvDMQLIYZEzv": true,     // Godric Gryffindor
        "-SL3ws2KvZQLTYMqzSas": true,     // Salazar Slytherin
        // More students
      }
    },
    "muggleStuddies": {
      "code": "SOC215",
      "enrolledStudents": {
        "-SL3ws2KvZQLTYMqzSas": true,     // Salazar Slytherin
        "-SL3ns2OtARSTUMywqWt": true,     // Some other student
        // More students
      }
    },
    // More courses
  }
}

ध्यान दें कि प्रत्येक छात्र के पास पाठ्यक्रमों की एक सूची है और प्रत्येक पाठ्यक्रम में नामांकित छात्रों की एक सूची है।

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

अधिकांश परिदृश्यों में जहां SQL जैसी क्वेरी की आवश्यकता होती है, डेटा को निष्क्रिय करना और दो-तरफ़ा संबंध बनाना आमतौर पर समाधान है।

उपरोक्त डेटाबेस का उपयोग करने वाले किसी अनुप्रयोग पर विचार करें जिसके लिए निम्न क्षमता की आवश्यकता है:

  1. उन पाठ्यक्रमों को सूचीबद्ध करें जिन्हें एक निश्चित छात्र ले रहा है और ...
  2. सभी छात्रों को एक निश्चित पाठ्यक्रम में सूचीबद्ध करें

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



Modified text is an extract of the original Stack Overflow Documentation
के तहत लाइसेंस प्राप्त है CC BY-SA 3.0
से संबद्ध नहीं है Stack Overflow