Sto costruendo un'app di mercato digitale. Mi piacerebbe sapere quali sono i modelli di progettazione delle best practice per l'archivio di oggetti backend (No SQL).
Le caratteristiche principali dell'app sono le seguenti:
- L'app presenta agli utenti una serie di elenchi modificabili (con funzionalità CRUD: crea, leggi, aggiorna, cancella).
- Esiste un marketplace principale (elenco di elementi visualizzabili e modificabili con dati specifici dell'utente.) Un esempio di questo sarebbe un elenco di prodotti in vendita e ogni utente sarebbe autorizzato a inserire la loro offerta sul prodotto. gli utenti potrebbero essere in grado di vedere le altre offerte ma solo modificare la propria offerta).
- Gli utenti avranno opinioni sulla propria attività. E la capacità di lavorare da quelle liste. Un esempio di questo sarebbe tutte le offerte non accettate. O tutti i prodotti offerti in vendita da parte dell'utente che hanno ricevuto offerte da altri utenti.
La mia domanda è, ci sono delle linee guida su come progettare al meglio l'architettura dei dati quando il back-end non è un negozio di oggetti SQL come Firebase?
Quello che segue è un esempio di una tale architettura delle migliori pratiche che cerco. Tuttavia, si occupa solo di una visualizzazione elenco. Quegli elementi aggiunti da un utente ma sono visibili solo all'utente che ha creato gli articoli. Ce ne sono altri?
NoSqlDataStoreroot/
|
- users/
|
- uid-xxxxxxxxxxxxxxxxxxxxxxxxxxxx/
|
- items/
|
+ Xxxxxxxxxxxxxxxxxxxxxabc123
|
+ Xxxxxxxxxxxxxxxxxxxxxabc124
|
+ Xxxxxxxxxxxxxxxxxxxxxabc125