Base de données axée sur le document (MongoDB?) Et facturation / commande?

Question

Nouveau sur les concepts de base de données axés sur les documents et possède quelques questions de haut niveau liées aux commandes et au traitement des commandes.

Comment capturer une commande dans ce monde? Une commande serait-elle juste un nouveau document dans un Orders le recueil? Aurait order_item relier à un product Inscrit dans un autre document? Ou est-il supposé que order_item serait copié et inséré dans le document de commande et donc, peut-être, difficile de signaler le total de product Vendu au fil du temps?

Comment contourner le manque de transactions et maintenir l'intégrité

Désolé, très nouveau pour moi bien que désireux de comprendre ... il semble très attrayant de résumer toutes ces «choses» à vendre en tant que «objets» et de les déplacer comme tels entre le serveur et les clients, etc ... si c'est bien plausible. Il suffit d'aider à conceptualiser les dos et à ne pas faire.

Answer 1

Comment capturer une commande dans ce monde? Une commande serait-elle simplement un nouveau document dans une collection de commandes?

Oui. C'est ainsi que ces bases de données fonctionnent.

Order_Item serait-il redevable à un produit répertorié dans un autre document?

Ça pourrait. Cela dépend de ce que vous faites.

Ou est-il supposé que Order_Item serait copié et inséré dans le document de commande

Aussi possible. Cela fonctionne bien pour l'analyse historique et l'entreposage de données.

Et ainsi, peut-être, difficile de signaler le total du produit vendu au fil du temps?

Il est toujours difficile de signaler le produit total vendu au fil du temps.

Aujourd'hui, le produit "23Skidoo" est un Framistat de 23L à contre-courant avec des widgets doubles.

L'année dernière, avant le rappel, le même produit était un Framistat à vallée à val-fermée de 23L avec un seul widget.

Au cours d'une année précédente, le même produit était en fait de 22,5 L.

Sont-ils le "même" produit? Le marketing les appelle tous "23Skidoo". Mais il y a des différences.

Une seule table de produit ne résout pas correctement. Ce que les gens font alors, c'est inventer les gammes de produits et les familles de produits afin qu'ils puissent introduire les produits "23Skidoo-B" et "23Skidoo-plus" qui font tous partie de la famille "23Skidoo".

Les gammes de produits et les familles de produits et autres groupes plus fantaisistes sont des solutions de contournement et des hacks pour faire magiquement des produits non apparentés ensemble et fournir un "produit total vendu au fil du temps" même si les produits sont clairement différents.

La copie du produit dans l'ordre (bien qu'elle semble inutile) peut préserver plus de fidélité historique que bon nombre des solutions de contournement couramment utilisées.

Comment contourner le manque de transactions et maintenir l'intégrité?

MongoDB a des verrous. http://www.mongodb.org/display/docs/how+does+CunCurrency+work.

On ne sait pas ce que vous entendez par manquer de transactions.

Answer 2

Il est donc toujours difficile de répondre à une question générique. Cependant, ce que je vous encourage à le faire examiner les modèles de lecture et d'écriture, vous vous attendez à ce que votre application fonctionne. Il y a des commandes pour certaines conceptions de documents, tout comme il y a des conceptions de schémas SGBDR.

Voici un lien vers une présentation de conception de schéma centrée sur MongoDB. Cela peut vous aider à comprendre certains de ces compromis et les options de conception.

http://www.scrip