Struttura dei dati e URL di Firebase

Sono nuovo in Firebase e nosql quindi abbi cura di me di usare il riferimento a sql. Quindi la mia domanda è come strutturare i dati in Firebase?

In firebase, si intende ogni “nuova base di fuoco” = “nuovo database” o “tabella” in mysql?

Se nella mia app web in tempo reale, ho utenti e commenti. In mysql, creerò un utente e una tabella dei commenti, quindi li collegherò insieme.

Come posso strutturare questo in Firebase?

Se hai utenti e commenti, puoi facilmente modellarlo in questo modo:

ROOT | +-- vzhen | | | +-- Vzhen's comment 1 | | | +-- Vzhen's comment 2 | +-- Frank van Puffelen | +-- Frank's comment 1 | +-- Frank's comment 2 

Tuttavia è più probabile che esista una terza quadro, come un articolo, e che gli utenti commentino (gli uni gli altri) articoli.

Firebase non ha il concetto di una chiave esterna, ma è facile da imitare. Se lo fai, puoi modellare la struttura utente / articolo / commento in questo modo:

 ROOT | +-- ARTICLES | | | +-- Text of article 1 (AID=1) | | | +-- Text of article 2 (AID=2) | +-- USERS | | | +-- vzhen (UID=1056201) | | | +-- Frank van Puffelen (UID=209103) | +-- COMMENTS | | | +-- Vzhen's comment on Article 1 (CID=1) | | | +-- Frank's response (CID=2) | | | +-- Frank's comment on article 2 (AID=2,UID=209103) | +-- ARTICLE_USER_COMMENT | +-- (AID=1,UID=1056201,CID=1) | +-- (AID=1,UID=209103,CID=2) | +-- (AID=2,UID=209103,CID=3) 

Questa è una mapping abbastanza diretta del modo in cui modellerai questo in un database relazionale. Il problema principale di questo modello è il numero di ricerche che devi fare per ottenere le informazioni necessarie per una singola schermata.

  1. Leggi l’articolo stesso (dal nodo ARTICOLI)
  2. Leggi le informazioni sui commenti (dal nodo ARTICLE_USER_COMMENT)
  3. Leggi il contenuto dei commenti (dal nodo COMMENTS)

A seconda delle esigenze, potrebbe anche essere necessario leggere anche il nodo USERS.

E ricorda che Firebase non ha il concetto di una clausola WHERE che ti consente di selezionare solo gli elementi di ARTICLE_USER_COMMENT che corrispondono a un articolo specifico oa un utente specifico.

In pratica questo modo di mappare la struttura non è utilizzabile. Firebase è una struttura gerarchica dei dati, quindi dovremmo usare le abilità uniche che ci danno rispetto al modello relazionale più tradizionale. Ad esempio: non abbiamo bisogno di un nodo ARTICLE_USER_COMMENT, possiamo semplicemente tenere queste informazioni direttamente sotto ogni articolo, utente e commento stesso.

Un piccolo frammento di questo:

 ROOT | +-- ARTICLES | | | +-- Text of article 1 (AID=1) | . | | . +-- (CID=1,UID=1056201) | . | | +-- (CID=2,UID=209103) | +-- USERS | | | +-- vzhen (UID=1056201) | . | | . +-- (AID=1,CID=1) | . | +-- COMMENTS | +-- Vzhen's comment on Article 1 (CID=1) | +-- Frank's response (CID=2) | +-- Frank's comment on article 2 (CID=3) 

Puoi vedere qui che stiamo diffondendo le informazioni da ARTICLE_USER_COMMENT sull’articolo e sui nodes utente. Questo è denormalizzare i dati un po ‘. Il risultato è che avremo bisogno di aggiornare più nodes quando un utente aggiunge un commento a un articolo. Nell’esempio sopra, dovremmo aggiungere il commento stesso e poi i nodes al nodo utente e nodo articolo rilevanti. Il vantaggio è che abbiamo meno nodes da leggere quando è necessario visualizzare i dati.

Se si porta questa denormalizzazione al massimo, si finisce con una struttura di dati come questa:

 ROOT | +-- ARTICLES | | | +-- Text of article 1 (AID=1) | | | | | +-- Vzhen's comment on Article 1 (UID=1056201) | | | | | +-- Frank's response (UID=209103) | | | +-- Text of article 2 (AID=2) | | | +-- Frank's comment on Article 2 (UID=209103) | +-- USERS | +-- vzhen (UID=1056201) | | | +-- Vzhen's comment on Article 1 (AID=1) | +-- Frank van Puffelen (UID=209103) | +-- Frank's response (AID=1) | +-- Frank's comment on Article 2 (AID=2) 

Puoi vedere che abbiamo eliminato i nodes COMMENTS e ARTICLE_USER_COMMENT in questo ultimo esempio. Tutte le informazioni su un articolo sono ora memorizzate direttamente sotto il nodo dell’articolo stesso, inclusi i commenti su quell’articolo (con un “link” all’utente che ha fatto il commento). E tutte le informazioni su un utente sono ora memorizzate sotto il nodo di quell’utente, inclusi i commenti che l’utente ha fatto (con un “link” all’articolo di cui parla il commento).

L’unica cosa che è ancora difficile su questo modello è il fatto che Firebase non ha un’API per attraversare tali “link”, quindi dovrai cercare l’utente / l’articolo da solo. Questo diventa molto più semplice se si utilizza l’UID / AID (in questo esempio) come nome del nodo che identifica l’utente / l’articolo.

Quindi questo porta al nostro modello finale:

 ROOT | +-- ARTICLES | | | +-- AID_1 | | | | | +-- Text of article 1 | | | | | +-- COMMENTS | | | | | +-- Vzhen's comment on Article 1 (UID=1056201) | | | | | +-- Frank's response (UID=209103) | | | +-- AID_2 | | | +-- Text of article 2 | | | +-- COMMENTS | | | +-- Frank's comment on Article 2 (UID=209103) | +-- USERS | +-- UID_1056201 | | | +-- vzhen | | | +-- COMMENTS | | | +-- Vzhen's comment on Article 1 (AID=1) | +-- UID_209103 | +-- Frank van Puffelen | +-- COMMENTS | +-- Frank's response (AID=1) | +-- Frank's comment on Article 2 (AID=2) 

Spero che questo aiuti a comprendere la modellazione gerarchica dei dati e i trade-off coinvolti.