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.
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.