Base de datos orientada a documentos (¿MongoDB?) Y facturación/pedido?

Question

Nuevo en conceptos de base de datos orientados a documentos y tiene algunas preguntas de alto nivel relacionadas con los pedidos y el procesamiento de pedidos.

¿Cómo se captura un pedido en este mundo? ¿Sería un pedido un documento nuevo en un Orders ¿recopilación? haría order_item relacionarse con un product listado en otro documento? O se supone que order_item sería copiado e insertado en el documento de pedido y, por lo tanto, quizás, difícil informar el total de product vendido con el tiempo?

¿Cómo se trabaja en torno a la falta de transacciones? y mantener la integridad

Lo siento, muy nuevo para mí, aunque ansioso por entender ... suena muy atractivo encapsular todas estas 'cosas' para la venta como "objetos" y moverlos como tales entre servidor y clientes, etc. si es realmente plausible. Solo necesito ayuda para conceptualizar grandes imágenes y no hacer.

Answer 1

¿Cómo se captura un pedido en este mundo? ¿Sería un pedido un nuevo documento en una colección de pedidos?

Sí. Así funcionan estas bases de datos.

¿Order_item se relacionaría con un producto que figura en otro documento?

Podria. Depende de lo que estés haciendo.

O se supone que Order_Item se copiaría e insertaría en el documento de pedido

También es posible. Esto funciona bien para el análisis histórico y el almacenamiento de datos.

¿Y por lo tanto, tal vez, difícil informar el total del producto vendido con el tiempo?

Siempre es difícil informar el producto total vendido con el tiempo.

Hoy, el producto "23skidoo" es un framistat de 23L, de válvulas abiertas, con widgets dobles.

El año pasado, antes del retiro, el mismo producto era un Framistat de 23L, válido cerrado con solo un widget.

En un año anterior, el mismo producto era en realidad 22.5L.

¿Son estos el "mismo" producto? El marketing los llama a todos "23skidoo". Pero hay diferencias.

Una sola tabla de productos no resuelve esto correctamente. Lo que la gente hace es inventar líneas de productos y familias de productos para que puedan presentar los productos "23skidoo-b" y "23skidoo-plus" que forman parte de la familia "23skidoo".

Las líneas de productos y las familias de productos y otras agrupaciones más fantasiosas son soluciones y hacks para hacer que los productos no relacionados informen juntos y proporcionen un "producto total vendido con el tiempo" a pesar de que los productos son claramente diferentes.

Copiar el producto en el orden (aunque parece un desperdicio) puede preservar más fidelidad histórica que muchas de las soluciones de uso común.

¿Cómo se trabaja en torno a la falta de transacciones y mantiene la integridad?

MongoDB tiene cerraduras. http://www.mongodb.org/display/docs/how+does+concurrency+work.

No está claro a qué te refieres con falta de transacciones.

Answer 2

Por lo tanto, siempre es difícil responder una pregunta genérica. Sin embargo, lo que le animaría a que lo haga, mira los patrones de lectura y escritura que espera que su aplicación realice. Hay compensaciones para ciertos diseños de documentos al igual que los diseños de esquema RDBMS.

Aquí hay un enlace a una presentación de diseño de esquema centrado en MongoDB. Puede ayudarlo a comprender algunas de estas compensaciones y opciones de diseño.

http://www.scribd.com/doc/47326395/mongoboulder-schema-design