Come modellerai il cliente> ordine> ordinativo> prodotto nel database NoSql?

Question

Attualmente sto imparando Node.JS e ho bisogno di implementare un database. Tutti i libri di Node sembrano pensare che MongoDB sia la soluzione migliore ma non riesco a capire come funziona il database NoSql come Mongo e Couch, sono un utente di MS SQL Server!

Così, ho capito che è possibile mantenere i dati strutturati come record (JSON), ma non sono sicuro di come si sarebbe modellare un tipico ecommerce app con le seguenti tabelle (semplificato) ...

customers (id, name, address) 
orders (id, customerID, orderDate) 
orderItems (id, orderID, productID) 
products (id, title, description, image) 

Così, di solito mi piacerebbe scrivere una query come questo (ma meglio ottimizzato ovviamente) ....

SELECT Customers.name, Products.title 
FROM (orders INNER JOIN customers ON orders.customerID = customers.id) 
INNER JOIN orderItems ON orderItems.orderID = orders.id 
INNER JOIN products ON orderItems.productID = products.id 

Se ho potuto vedere un esempio di come questo dovrebbe funzionare in un database NoSQL allora potrei iniziare a " prendilo".

In alternativa, sto semplicemente meglio attenersi a MSSQL Server o MySql, entrambi comunque compatibili con Node?

Answer 1

Una considerazione importante quando si progetta uno schema per MongoDB non è ciò che sono i tuoi dati, ma come li utilizzerai. Senza elaborare il tipo di letture e scritture che farai (e quanto saranno performanti), può essere difficile progettare uno schema "ottimale".

Esistono alcune linee guida di base che è possibile prendere in considerazione per evitare di incorrere in problemi. Uno di questi è evitare di progettare documenti che continuano a crescere senza limiti. Ciò significa che non devi incorporare gli ordini nei documenti del cliente. Un'altra regola è che le cose che non sono "di interesse" da sole (o che non esistono da sole) sono probabilmente meglio incorporate. Ciò suggerisce che gli ordini non meritano la propria collezione e dovrebbero semplicemente essere trattati come attributi di ordini (che è ciò che sono, in effetti).

Questo esercizio esatto è coperto dalla formazione per sviluppatori di MongoDB, essendo un tipico esempio di progettazione di schemi.

Linea di fondo è che si dovrebbe avere tre collezioni:

Prodotti
clienti
Ordini

Ordini farà riferimento clienti (opzionalmente denormalizing alcune informazioni da collezione cliente) e si farà riferimento prodotti (in matrice di ordini che conterranno).

Ulteriori raccolte e campi esatti in tutte queste raccolte dipendono dal caso d'uso specifico, ma non riesco a vedere uno scenario fattibile per avere meno raccolte rispetto a queste tre.

Answer 2

Mongo utilizza le raccolte, che potresti in qualche modo correlare a "tabelle", quindi potresti avere 4 raccolte qui. Tuttavia, non c'è motivo per cui non sia possibile combinare "ordini" e "articoli dell'ordine" in "ordini", poiché è necessario considerare che ciascuna voce può essere più di un documento che è possibile ottenere con gli RDBMS.

Il divano è diverso, dove si archiviano semplicemente i documenti. In questo caso è possibile contrassegnare ogni documento con il "tipo" di documento che è. È quindi possibile creare funzioni di visualizzazione che possono restituire i dati necessari tramite mappa/riduzione.

Con nessuno di questi, non rimanere troppo agitato nel fare tutto in una query, poiché non è sempre possibile.

Qui il punto chiave è che non esiste un unico approccio "NoSQL" a differenza di RDBMS in cui SQL è l'unificatore. Ogni DB e tipo di negozio NoSQL ha i suoi lati positivi e gli svantaggi, e dovrai determinare quale sia la soluzione migliore per te.

Spero che questo aiuti.