Join us for Firebase Summit on November 10, 2021. Tune in to learn how Firebase can help you accelerate app development, release with confidence, and scale with ease. Register

בנה את מסד הנתונים שלך

לפני שאתה מתחיל

לפני שתוכל להשתמש מסד זמן אמת , עליך:

  • רשום את פרויקט Unity והגדר אותו לשימוש ב- Firebase.

    • אם פרויקט Unity שלך כבר משתמש ב- Firebase, הוא כבר רשום ומוגדר עבור Firebase.

    • אם אין לך פרויקט אחדות, אתה יכול להוריד אפליקציה לדוגמא .

  • מוסיפים את SDK האחדות Firebase (במיוחד, FirebaseDatabase.unitypackage ) לפרויקט האחדות שלך.

שים לב כי הוספת Firebase לפרויקט האחדות שלך כרוך משימות הן Firebase הקונסולה ו בפרויקט האחדות פתוח (למשל, אתה מוריד קבצי config Firebase מהמסוף, ולאחר מכן להעביר אותם לתוך פרויקט האחדות שלכם).

מבנה נתונים

מדריך זה מכסה כמה מושגי המפתח בארכיטקטורת נתונים ושיטות עבודה מומלצות לבניית נתוני JSON במאגר הנתונים שלך בזמן אמת של Firebase.

בניית מסד נתונים מובנה כנדרש דורשת לא מעט מחשבה מוקדמת. והכי חשוב, אתה צריך לתכנן כיצד הנתונים יישמרו ויאוחזרו מאוחר יותר כדי להפוך את התהליך לקל ככל האפשר.

אופן בניית הנתונים: זהו עץ 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, ניתן לייצג נתונים המאוחסנים במסד הנתונים כסוגים מקוריים מסוימים התואמים לסוגי 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": { ... }
  }
}

כעת ניתן לחזור על רשימת החדרים על ידי הורדת מספר בתים בלבד לשיחה, אחזור מהיר של מטא נתונים לרישום או הצגת חדרים בממשק משתמש. ניתן להביא הודעות בנפרד ולהציג אותן כשהן מגיעות, ומאפשרות לממשק המשתמש להישאר מגיב ומהיר.

יצירת נתונים בקנה מידה

כאשר בונים אפליקציות, לרוב עדיף להוריד קבוצת משנה של רשימה. הדבר נפוץ במיוחד אם הרשימה מכילה אלפי רשומות. כאשר מערכת יחסים זו היא סטטית וחד כיוונית, אתה יכול פשוט לקנן את אובייקטים הילד מתחת להורה.

לפעמים, מערכת יחסים זו היא דינאמית יותר, או שיהיה צורך להפוך את הנתונים הללו לא -נורמליים. הרבה פעמים אתה יכול בטל נורמליזציה הנתונים באמצעות שאילתה לאחזור קבוצת משנה של הנתונים, כפי שפורט לאחזר נתונים .

אבל אפילו זה עשוי להיות לא מספיק. שקול, למשל, מערכת יחסים דו כיוונית בין משתמשים לקבוצות. משתמשים יכולים להשתייך לקבוצה, וקבוצות מהוות רשימת משתמשים. כאשר מגיע הזמן להחליט לאילו קבוצות משתמש משתייך, העניינים מסתבכים.

מה שצריך הוא דרך אלגנטית לרשום את הקבוצות שאליהן משתייך משתמש ולאסוף רק נתונים עבור קבוצות אלה. אינדקס של קבוצות יכול לסייע במידה רבה כאן:

// 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 מופיע בפרופיל של העדה. אז כדי למחוק את עדה מהקבוצה, יש לעדכן אותה בשני מקומות.

זוהי יתירות הכרחית למערכות יחסים דו כיווניות. הוא מאפשר לך להשיג במהירות וביעילות את החברות של עדה, גם כאשר רשימת המשתמשים או הקבוצות מסתכמים במיליונים או כאשר כללי האבטחה של מסד הנתונים בזמן אמת מונעים גישה לחלק מהרשומות.

גישה זו, היפוך הנתונים על ידי הוספת המזהים כמפתחות הגדרת הערך אמיתי, עושה בדיקת מפתח פשוט כמו קריאה /users/$uid/groups/$group_id ובדיקה אם הוא null . האינדקס מהיר יותר והרבה יותר יעיל מאשר בירור או סריקה של הנתונים.

הצעדים הבאים