Wie würden Sie das Produkt> Kunde> Bestellung> Produkt in der NoSql-Datenbank modellieren?

Question

Ich lerne gerade Node.JS und muss eine Datenbank implementieren. Alle Knotenbücher scheinen MongoDB für die beste Lösung zu halten, aber ich kann mich nicht mit NoSql-Datenbanken wie Mongo und Couch herumschlagen, ich bin ein MS SQL Server-Typ!

Also, ich verstehe, dass Sie strukturierte Daten als Datensätze (JSON) halten kann, aber ich bin mir nicht sicher, wie Sie mit den folgenden (vereinfacht) Tabellen eine typische E-Commerce-App modellieren würde ...

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

Also, normalerweise würde ich eine Abfrage wie folgt (aber besser optimiert natürlich) ....

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 

schreiben Wenn ich ein Beispiel sehen konnte, wie diese dann in einer NoSQL-Datenbank arbeiten, würde ich anfangen könnte " Hole es".

Oder bin ich besser dran mit MSSQL Server oder MySql, die beide mit Node sowieso kompatibel sind?

Answer 1

Eine wichtige Überlegung beim Entwerfen eines Schemas für MongoDB ist nicht, was Ihre Daten sind, sondern wie Sie sie verwenden. Ohne herauszufinden, welche Arten von Lese- und Schreibvorgängen Sie tun werden (und wie leistungsfähig sie sein werden), kann es schwierig sein, ein "optimales" Schema zu entwerfen.

Es gibt einige grundlegende Richtlinien, die Sie berücksichtigen können, um Probleme zu vermeiden. Einer von ihnen ist es, Dokumente zu vermeiden, die unbegrenzt wachsen. Das heißt, Sie sollten keine Bestellungen in Kundendokumente einbetten. Eine andere Regel ist, dass Dinge, die für sich allein nicht von Interesse sind (oder nicht für sich allein existieren), wahrscheinlich besser eingebettet sind. Dies legt nahe, dass Order Items ihre eigene Sammlung nicht verdienen und einfach als Attribute von Orders behandelt werden sollten (was sie tatsächlich sind).

Diese genaue Übung wird in MongoDB Entwicklerschulung behandelt, ein ziemlich typisches Beispiel für Schemadesign.

Unterm Strich ist, dass Sie drei Kollektionen haben sollten:

Produkte
Kunden
Bestellungen

Bestellungen Kunden (optional Denormalisierung einige Informationen von Kunden-Sammlung), und sie werden Referenz-Produkte (in der wird das Bezugs Array von Order Items sie enthalten).

Weitere Sammlungen und genaue Felder in all diesen Sammlungen hängen von Ihrem spezifischen Anwendungsfall ab, aber ich kann kein praktikables Szenario für weniger Sammlungen als diese drei sehen.

Answer 2

Mongo verwendet Sammlungen, die Sie irgendwie mit "Tabellen" in Beziehung setzen könnten, so dass Sie hier 4 Sammlungen haben könnten. Aber es gibt keinen Grund, warum Sie "Bestellungen" und "Bestellartikel" nicht in "Bestellungen" zusammenfassen könnten, da Sie jeden Eintrag als ein Dokument betrachten können, das Sie mit RDBMS erreichen können.

Couch ist anders, wo Sie einfach Dokumente speichern. In diesem Fall können Sie jedes Dokument mit dem "Typ" des Dokuments markieren. Sie können dann Ansichtsfunktionen erstellen, die die benötigten Daten über map/reduce zurückgeben können.

Mit einer dieser Fragen, nicht zu viel auf alles in einer Abfrage tun, da es nicht immer möglich ist.

Kernpunkt hier ist, gibt es keine einzige "NoSQL" -Ansatz zu diesem, im Gegensatz zu RDBMS, wo SQL der Unifier ist. Jede DB und jeder Typ von NoSQL-Speicher hat seine Vor- und Nachteile, und Sie müssen bestimmen, was am besten für Sie passt.

Hoffe, das hilft.