আপনার ডাটাবেস গঠন

এই নির্দেশিকাটি ডেটা আর্কিটেকচারের কিছু মূল ধারণা এবং আপনার Firebase Realtime Database JSON ডেটা গঠনের জন্য সর্বোত্তম অনুশীলনগুলি কভার করে।

একটি সুসংগঠিত ডাটাবেস তৈরি করতে বেশ কিছু পূর্বচিন্তা প্রয়োজন। সবচেয়ে গুরুত্বপূর্ণ বিষয় হল, আপনাকে পরিকল্পনা করতে হবে কিভাবে ডেটা সংরক্ষণ করা হবে এবং পরে পুনরুদ্ধার করা হবে যাতে প্রক্রিয়াটি যতটা সম্ভব সহজ হয়।

ডেটা কীভাবে গঠন করা হয়: এটি একটি JSON ট্রি

সমস্ত Firebase Realtime Database ডেটা JSON অবজেক্ট হিসেবে সংরক্ষণ করা হয়। আপনি ডাটাবেসটিকে ক্লাউড-হোস্টেড JSON ট্রি হিসেবে ভাবতে পারেন। SQL ডাটাবেসের বিপরীতে, কোনও টেবিল বা রেকর্ড থাকে না। যখন আপনি JSON ট্রিতে ডেটা যোগ করেন, তখন এটি একটি সংযুক্ত কী সহ বিদ্যমান JSON কাঠামোর একটি নোডে পরিণত হয়। আপনি আপনার নিজস্ব কী প্রদান করতে পারেন, যেমন ব্যবহারকারী আইডি বা শব্দার্থিক নাম, অথবা push() ব্যবহার করে আপনার জন্য সেগুলি প্রদান করা যেতে পারে।

উদাহরণস্বরূপ, একটি চ্যাট অ্যাপ্লিকেশন বিবেচনা করুন যা ব্যবহারকারীদের একটি মৌলিক প্রোফাইল এবং পরিচিতি তালিকা সংরক্ষণ করতে দেয়। একটি সাধারণ ব্যবহারকারী প্রোফাইল একটি পাথে অবস্থিত, যেমন /users/$uid । ব্যবহারকারী alovelace একটি ডাটাবেস এন্ট্রি থাকতে পারে যা দেখতে এরকম কিছু:

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

যদিও ডাটাবেসটি একটি JSON ট্রি ব্যবহার করে, ডাটাবেসে সংরক্ষিত ডেটা নির্দিষ্ট নেটিভ টাইপ হিসাবে উপস্থাপন করা যেতে পারে যা উপলব্ধ JSON টাইপের সাথে মিলে যায় যা আপনাকে আরও রক্ষণাবেক্ষণযোগ্য কোড লিখতে সাহায্য করে।

ডেটা স্ট্রাকচারের জন্য সেরা অনুশীলন

ডেটা নেস্টিং এড়িয়ে চলুন

যেহেতু Firebase Realtime Database ৩২ স্তর পর্যন্ত ডেটা নেস্ট করার অনুমতি দেয়, তাই আপনি ভাবতে প্রলুব্ধ হতে পারেন যে এটিই ডিফল্ট কাঠামো হওয়া উচিত। তবে, যখন আপনি আপনার ডাটাবেসের কোনও স্থানে ডেটা আনেন, তখন আপনি এর সমস্ত চাইল্ড নোডও পুনরুদ্ধার করেন। এছাড়াও, যখন আপনি কাউকে আপনার ডাটাবেসের কোনও নোডে পড়ার বা লেখার অ্যাক্সেস দেন, তখন আপনি তাদের সেই নোডের অধীনে থাকা সমস্ত ডেটাতে অ্যাক্সেসও দেন। অতএব, বাস্তবে, আপনার ডেটা কাঠামো যতটা সম্ভব সমতল রাখাই ভাল।

নেস্টেড ডেটা কেন খারাপ তার একটি উদাহরণের জন্য, নিম্নলিখিত মাল্টিপ্লাই-নেস্টেড কাঠামোটি বিবেচনা করুন:

{
  // 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-তে রুম তালিকাভুক্ত বা প্রদর্শনের জন্য মেটাডেটা আনে। বার্তাগুলি আলাদাভাবে আনা যেতে পারে এবং আসার সাথে সাথে প্রদর্শিত হতে পারে, যা UI-কে প্রতিক্রিয়াশীল এবং দ্রুত থাকতে দেয়।

স্কেল করে এমন ডেটা তৈরি করুন

অ্যাপ তৈরি করার সময়, তালিকার একটি উপসেট ডাউনলোড করা প্রায়শই ভালো। এটি বিশেষ করে যদি তালিকায় হাজার হাজার রেকর্ড থাকে তবে সাধারণ। যখন এই সম্পর্কটি স্থির এবং একমুখী হয়, তখন আপনি কেবল চাইল্ড অবজেক্টগুলিকে প্যারেন্টের অধীনে রাখতে পারেন।

কখনও কখনও, এই সম্পর্কটি আরও গতিশীল হয়, অথবা এই ডেটাটিকে ডিনরমালাইজ করার প্রয়োজন হতে পারে। অনেক সময় আপনি ডেটার একটি উপসেট পুনরুদ্ধার করার জন্য একটি কোয়েরি ব্যবহার করে ডেটা ডিনরমালাইজ করতে পারেন, যেমনটি Retrieve Data -তে আলোচনা করা হয়েছে।

কিন্তু এমনকি এটিও যথেষ্ট নাও হতে পারে। উদাহরণস্বরূপ, ব্যবহারকারী এবং গোষ্ঠীর মধ্যে দ্বিমুখী সম্পর্কের কথা বিবেচনা করুন। ব্যবহারকারীরা একটি গোষ্ঠীর অন্তর্ভুক্ত হতে পারেন এবং গোষ্ঠীগুলি ব্যবহারকারীদের একটি তালিকা নিয়ে গঠিত। যখন কোনও ব্যবহারকারী কোন গোষ্ঠীর অন্তর্ভুক্ত তা নির্ধারণ করার সময় আসে, তখন বিষয়গুলি জটিল হয়ে ওঠে।

ব্যবহারকারীর অন্তর্ভুক্ত গ্রুপগুলির তালিকা তৈরি করার এবং শুধুমাত্র সেই গ্রুপগুলির জন্য ডেটা সংগ্রহ করার একটি মার্জিত উপায় প্রয়োজন। গ্রুপগুলির একটি সূচী এখানে অনেক সাহায্য করতে পারে:

// 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 অ্যাডার প্রোফাইলে তালিকাভুক্ত হয়। তাই গ্রুপ থেকে অ্যাডা মুছে ফেলার জন্য, এটি দুটি জায়গায় আপডেট করতে হবে।

দ্বিমুখী সম্পর্কের জন্য এটি একটি প্রয়োজনীয় অতিরিক্ত সুবিধা। এটি আপনাকে দ্রুত এবং দক্ষতার সাথে অ্যাডার সদস্যপদ সংগ্রহ করতে সাহায্য করে, এমনকি যখন ব্যবহারকারী বা গোষ্ঠীর তালিকা লক্ষ লক্ষে পৌঁছায় অথবা যখন Realtime Database সুরক্ষা নিয়ম কিছু রেকর্ডে অ্যাক্সেস বাধাগ্রস্ত করে।

এই পদ্ধতিতে, আইডিগুলিকে কী হিসেবে তালিকাভুক্ত করে এবং মানকে সত্যে সেট করে ডেটা উল্টে দেওয়া হয়, যা /users/$uid/groups/$group_id পড়া এবং এটি null কিনা তা পরীক্ষা করার মতোই একটি কী পরীক্ষা করা সহজ করে তোলে। সূচকটি দ্রুত এবং ডেটা অনুসন্ধান বা স্ক্যান করার চেয়ে অনেক বেশি দক্ষ।

পরবর্তী পদক্ষেপ