firebase
Strukturera data

Introduktion

Do's and Don'ts

Fel väg

Tänk på följande struktur

{
  "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
  }
}

Detta är ett bra exempel på vad du INTE ska göra. Multi-nestade strukturer som ovanstående kan vara mycket problematiska och kan orsaka ett stort bakslag i prestanda.

Hur Firebase får åtkomst till en nod är genom att ladda ner alla barnens data och sedan iterera över alla noder på samma nivå (alla föräldrarnas barn). Föreställ dig nu en databas med flera användare , var och en med hundratals (eller till och med tusentals) inlägg . Att komma åt ett inlägg i det här fallet kan potentiellt ladda hundratals megabyte oanvänd data. I en mer komplicerad applikation kan häckningen vara djupare än bara fyra lager, vilket skulle resultera i mer värdelösa nedladdningar och iterationer.

Den rätta vägen

Att platta ut samma struktur skulle se ut så här

{
  // "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
  }
}

Detta sparar en enorm mängd overhead genom att iterera över mindre noder för att komma åt ett målobjekt. Alla användare som inte har några inlägg skulle inte existera i inläggsgrenen , och så att iterera över dessa användare på fel sätt ovan är helt värdelöst.

Tvåvägsrelationer

Följande är ett exempel på en enkel och minimal college-databas som använder tvåvägsrelationer

{
  "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
  }
}

Observera att varje student har en lista över kurser och varje kurs har en lista över inskrivna studenter .

Redundans är inte alltid ett dåligt tillvägagångssätt. Det är sant att det kostar lagringsutrymme och att hantera uppdateringar av flera poster när du raderar eller redigerar en duplicerad nod; Men i vissa scenarier där data inte uppdateras ofta, kan det att ha tvåvägsrelationer underlätta hämtnings- / skrivprocessen betydligt.

I de flesta scenarier där en SQL-liknande fråga verkar behövs, är det vanligtvis lösningen att invertera data och skapa tvåvägsrelationer.

Överväg en applikation som använder databasen ovan som kräver förmågan att:

1. Lista de kurser en viss student tar och ...
2. Lista alla elever på en viss kurs

Om databasstrukturen hade varit i en riktning, skulle det otroligt långsammare att skanna eller fråga efter ett av de två kraven ovan. I vissa scenarier gör redundans ofta operationer snabbare och mycket effektivare, vilket på längre sikt gör dubbletternas kostnader försumbara.