Google is committed to advancing racial equity for Black communities. See how.
Questa pagina è stata tradotta dall'API Cloud Translation.
Switch to English

Strutturazione dei dati con Firebase Realtime Database for C ++

Dati di strutturazione

Questa guida copre alcuni dei concetti chiave nell'architettura dei dati e le best practice per strutturare i dati JSON nel tuo Firebase Realtime Database.

La creazione di un database adeguatamente strutturato richiede un po 'di accortezza. Ancora più importante, è necessario pianificare il modo in cui i dati verranno salvati e successivamente recuperati per rendere il processo il più semplice possibile.

Come sono strutturati i dati: è un albero JSON

Tutti i dati di Firebase Realtime Database vengono archiviati come oggetti JSON. Puoi pensare al database come a un albero JSON ospitato nel cloud. A differenza di un database SQL, non ci sono tabelle o record. Quando aggiungi dati all'albero JSON, diventa un nodo nella struttura JSON esistente con una chiave associata. È possibile fornire chiavi personalizzate, come ID utente o nomi semantici, oppure possono essere fornite utilizzando il metodo Push() .

Se crei le tue chiavi, devono essere codificate UTF-8, possono essere un massimo di 768 byte e non possono contenere . , $ , # , [ , ] , / o caratteri di controllo ASCII 0-31 o 127. Non è possibile utilizzare nemmeno i caratteri di controllo ASCII nei valori stessi.

Si consideri ad esempio un'applicazione di chat che consente agli utenti di memorizzare un profilo di base e un elenco di contatti. Un tipico profilo utente si trova in un percorso, come /users/$uid . L'utente alovelace potrebbe avere una voce di database simile a questa:

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

Sebbene il database utilizzi un albero JSON, i dati archiviati nel database possono essere rappresentati come determinati tipi nativi che corrispondono ai tipi JSON disponibili per aiutarti a scrivere codice più gestibile.

Best practice per la struttura dei dati

Evita di annidare i dati

Poiché Firebase Realtime Database consente di annidare dati fino a 32 livelli di profondità, potresti essere tentato di pensare che questa dovrebbe essere la struttura predefinita. Tuttavia, quando si recuperano i dati in una posizione nel database, si recuperano anche tutti i relativi nodi figlio. Inoltre, quando concedi a qualcuno l'accesso in lettura o scrittura a un nodo del tuo database, gli concedi anche l'accesso a tutti i dati in quel nodo. Pertanto, in pratica, è meglio mantenere la struttura dei dati il ​​più piatta possibile.

Per un esempio del motivo per cui i dati nidificati sono errati, considera la seguente struttura nidificata multipla:

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

Con questo design annidato, l'iterazione dei dati diventa problematica. Ad esempio, l'elenco dei titoli delle conversazioni in chat richiede il download dell'intero albero delle chats , inclusi tutti i membri e i messaggi, sul client.

Appiattisci le strutture dati

Se i dati vengono invece suddivisi in percorsi separati, chiamati anche denormalizzazione, possono essere efficacemente scaricati in chiamate separate, in quanto necessario. Considera questa struttura appiattita:

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

È ora possibile scorrere l'elenco delle stanze scaricando solo pochi byte per conversazione, recuperando rapidamente i metadati per l'elenco o la visualizzazione delle stanze in un'interfaccia utente. I messaggi possono essere recuperati separatamente e visualizzati quando arrivano, consentendo all'interfaccia utente di rimanere reattiva e veloce.

Crea dati scalabili

Quando si creano app, spesso è meglio scaricare un sottoinsieme di un elenco. Ciò è particolarmente comune se l'elenco contiene migliaia di record. Quando questa relazione è statica e unidirezionale, puoi semplicemente nidificare gli oggetti figlio sotto il genitore.

A volte, questa relazione è più dinamica o potrebbe essere necessario denormalizzare questi dati. Molte volte è possibile denormalizzare i dati utilizzando una query per recuperare un sottoinsieme di dati, come discusso in Recuperare dati .

Ma anche questo potrebbe essere insufficiente. Si consideri, ad esempio, una relazione a due vie tra utenti e gruppi. Gli utenti possono appartenere a un gruppo e i gruppi comprendono un elenco di utenti. Quando arriva il momento di decidere a quali gruppi appartiene un utente, le cose si complicano.

Ciò che serve è un modo elegante per elencare i gruppi a cui appartiene un utente e recuperare solo i dati per quei gruppi. Un indice di gruppi può aiutare molto qui:

// 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
      }
    },
    ...
  }
}

Potresti notare che questo duplica alcuni dati archiviando la relazione sia nel record di Ada che nel gruppo. Ora alovelace è indicizzato sotto un gruppo e techpioneers è elencato nel profilo di Ada. Quindi, per eliminare Ada dal gruppo, deve essere aggiornato in due punti.

Questa è una ridondanza necessaria per le relazioni a due vie. Ti consente di recuperare in modo rapido ed efficiente le iscrizioni di Ada, anche quando l'elenco di utenti o gruppi arriva a milioni o quando le regole di sicurezza del database in tempo reale impediscono l'accesso ad alcuni record.

Questo approccio, invertendo i dati elencando gli ID come chiavi e impostando il valore su true, rende il controllo di una chiave semplice come leggere /users/$uid/groups/$group_id e controllare se è null . L'indice è più veloce e molto più efficiente rispetto all'interrogazione o alla scansione dei dati.

Prossimi passi