আপনার ডেটাবেস স্ট্রাকচার করা

এই গাইডে ডেটা আর্কিটেকচারের কিছু মূল ধারণা এবং আপনার 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-কে রেসপন্সিভ এবং দ্রুত থাকতে সাহায্য করে।

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

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

কখনও কখনও, এই সম্পর্ক আরও ডাইনামিক হয় অথবা এই ডেটা ডিনর্মালাইজ করার প্রয়োজন হতে পারে। অনেক সময় আপনি কোয়েরি ব্যবহার করে ডেটা ডিনর্মালাইজ করতে পারেন যাতে ডেটার সাবসেট ফিরিয়ে আনা যায়, যেমন ডেটা ফিরিয়ে আনা বিভাগে আলোচনা করা হয়েছে।

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

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

// 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-র মেম্বারশিপ দ্রুত ও দক্ষতার সাথে নিয়ে আসতে দেয়, এমনকি ব্যবহারকারী বা গ্রুপের তালিকা লক্ষাধিক হলেও বা Realtime Database নিরাপত্তা সংক্রান্ত নিয়ম কিছু রেকর্ডে অ্যাক্সেস করতে বাধা দিলেও।

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

পরবর্তী ধাপ

• আপনার Realtime Database-এ ডেটা সেভ করুন
• আপনার Realtime Database থেকে ডেটা ফিরিয়ে আনা