Sto pianificando correttamente il mio database / back-end?

Un po 'sui database relazionali

Una delle funzionalità più potenti dei database relazionali è la possibilità di connettere insiemi di dati attraverso punti comuni. Per farlo in modo efficiente, un database dovrebbe seguire le regole della normalizzazione . Per sommare queste regole, un database dovrebbe avere:

1. Nessun elemento ripetuto o gruppo di elementi
2. Nessuna dipendenza parziale su una chiave concatenata
3. Nessuna dipendenza dagli attributi non chiave

Tenendo presenti queste regole, una tabella di esempio per i commenti potrebbe essere simile a questa:

----------------------------------------------------------------------    
| comments                                                           |
|--------------------------------------------------------------------|
| comment_id (key, auto-increment) |  comment  | post_id |  user_id  |
|----------------------------------|-----------|---------|-----------|
| 1                                | <text...> |    1    |   123452  |
----------------------------------------------------------------------   

Qui, comment_id è la "chiave" o identificatore univoco della tabella. È anche stato impostato su "incremento automatico", il che significa che aumenterà automaticamente il suo valore come "record" o righe, vengono aggiunti alla tabella. Come mostrato, la tabella contenente le informazioni relative ai commenti sa solo cosa ha bisogno di sapere. In che modo, quindi, metti in relazione le informazioni specifiche dell'utente con un commento? È qui che entra in gioco la parte "relazionale" del "database relazionale":

--------------------------------------------|
| users                                     |
|-------------------------------------------|--------------------------------|
| user_id (key, auto-increment) |   avatar  | additional fields not shown... |
|-------------------------------|-----------|--------------------------------|
| 123452                        | <img_url> |
---------------------------------------------

Tieni presente che la colonna user_id contiene gli stessi dati sia per la tabella comments che per la tabella users . In questo modo, puoi "unire" i dati delle due tabelle. Ad esempio, per ottenere tutti i commenti fatti da un utente, è possibile eseguire la query MySQL:

SELECT comment_id, comment, post_id FROM comments NATURAL JOIN users WHERE user_id=123452;

Questo metodo risponde anche alla domanda

how should the user should keep track of all of their posts, comments, and favorites?

La tabella user non dovrebbe tenere traccia di tali informazioni in sé, ma piuttosto le rispettive tabelle dovrebbero contenere riferimenti a un ID utente globalmente unico.

Quasi lì

Quindi, in sostanza, eri sulla buona strada. L'unico vero cambiamento dal modello che hai specificato è stato spostare le informazioni dell'avatar dell'utente nella tabella relativa agli utenti, invece che nella tabella relativa ai commenti.

Come sembra che tu stia distogliendo dall'uso di un database SQL raw, potresti considerare le tabelle come classi e utilizzare le regole di normalizzazione come linee guida per la progettazione.

Infine, la cosa di Pointers vs. Arrays: entrambi sono molto specifici del backend di Parse (e, ammettiamolo, nessuno dei due è spiegato molto bene). Il miglior confronto che riesco a fare è che i Puntatori sarebbero come Liste (come in Java o C #), e gli Array sarebbero come, beh, gli Array. La differenza tra i due è che gli array possono solo memorizzare una quantità predeterminata di dati, mentre gli elenchi (o puntatori, nel caso di Parse) possono memorizzare una quantità non specificata. In teoria, la quantità sarebbe infinita, ma in pratica la quantità è determinata dalla quantità di spazio disponibile nell'heap. Per ulteriori informazioni sulla differenza tra elenchi e array, consulta questa domanda . Se stai pianificando di utilizzare Parse, ti consiglio di utilizzare i puntatori in congiunzione con le tabelle di join (che sono essenzialmente wrapper attorno al metodo SQL descritto sopra), poiché queste sono le opzioni che offrono la massima flessibilità.