بانک اطلاعاتی خود را ساختار دهید

این راهنما برخی از مفاهیم کلیدی در معماری داده ها و بهترین شیوه ها برای ساختاردهی داده های JSON در پایگاه داده Firebase Realtime شما را پوشش می دهد.

ایجاد یک پایگاه داده با ساختار مناسب ، نیاز به کمی دقت دارد. مهمتر از همه ، شما باید برای نحوه ذخیره و بازیابی اطلاعات برنامه ریزی کنید تا این فرآیند تا حد امکان آسان شود.

نحوه ساختار داده ها: این یک درخت JSON است

همه داده های پایگاه داده Firebase Realtime به عنوان اشیاء 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 اجازه می دهد تا داده ها را تا عمق 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
      }
    },
    ...
  }
}

ممکن است توجه داشته باشید که این داده ها را با ذخیره رابطه هم در رکورد آدا و هم در گروه ، برخی داده ها را تکراری می کند. حالا alovelace تحت گروه نمایه، و techpioneers در مشخصات آدا ذکر شده است. بنابراین برای حذف Ada از گروه ، باید در دو مکان به روز شود.

این یک افزونگی ضروری برای روابط دو طرفه است. این به شما امکان می دهد تا سریع و کارآمد عضویت های Ada را دریافت کنید ، حتی زمانی که لیست کاربران یا گروه ها به میلیون ها نفر برسد یا قوانین امنیتی Realtime Database از دسترسی به برخی از سوابق جلوگیری می کند.

این رویکرد، معکوس داده با لیست شناسه به عنوان کلید و تنظیم مقدار به درست، باعث می شود که برای چک کردن یک کلید به عنوان ساده به عنوان خواندن /users/$uid/groups/$group_id و چک کردن آن است که اگر null . این شاخص سریعتر و کارآمدتر از پرس و جو یا اسکن داده ها است.

مراحل بعدی