MongoDB in Ecommerce. Is it good idea?

[Julie]

Hi,

I plan to use MongoDB and Ruby on Rails in Ecommerce. It will use
PayPal express checkout. Do you guys think MongoDB support Ecommerce?

Thanks,
Julie

[Julie]

After more reading: from MongoDB doc
"To get great performance and horizontal scalability however, MongoDB
gives something up: transactions. MongoDB does not support
transactions that span multiple collections. You can do atomic
operations on a single object, but you can’t modify objects from two
collections atomically."

Do you guys know what it means by "does not support transactions that
span multiple collections". Is it means, it does not able to store
session?

[Kyle Banker]

MongoDB will work well for 90% of an e-commerce site. It will be especially strong when it comes to catalog management. You can definitely store sessions in MongoDB, too.  Depending on how you model things, you should be able to use the atomic operations within a single document to handle your shopping cart and line items. If you're handling inventory management, you may need full-fledged transactions. If that's the case, it might make sense to take a hybrid approach, using MySQL for the transactional side of the app and MongoDB for everything else.

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Julie]

Thanks for the reply. I am reading all over the net to get as much
correct info.

So the ecommerce stuff that I want to do does not have inventory
management. It only has purchasing digital item through paypal express
checkout. Once checkout transaction complete, it will record it for
reporting/billing purpose. The ecommerce will have have the option of
monthly subscription which will have recurring monthly credit card
transaction.

Seems like, I might have these structure.
User has address
has credit card info
has billing report
has purchased digital goods

Thanks,
Julie

On Mar 9, 7:20 am, Kyle Banker <k...@10gen.com> wrote:
> MongoDB will work well for 90% of an e-commerce site. It will be especially
> strong when it comes to catalog management. You can definitely store
> sessions in MongoDB, too.  Depending on how you model things, you should be
> able to use the atomic operations within a single document to handle your
> shopping cart and line items. If you're handling inventory management, you
> may need full-fledged transactions. If that's the case, it might make sense
> to take a hybrid approach, using MySQL for the transactional side of the app
> and MongoDB for everything else.
>

> On Tue, Mar 9, 2010 at 10:05 AM, Julie <julie44...@gmail.com> wrote:
> > After more reading: from MongoDB doc
> > "To get great performance and horizontal scalability however, MongoDB
> > gives something up: transactions. MongoDB does not support
> > transactions that span multiple collections. You can do atomic
> > operations on a single object, but you can’t modify objects from two
> > collections atomically."
>
> > Do you guys know what it means by "does not support transactions that
> > span multiple collections". Is it means, it does not able to store
> > session?
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "mongodb-user" group.
> > To post to this group, send email to mongod...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > mongodb-user...@googlegroups.com<mongodb-user%2Bunsu...@googlegroups.com>

[Julie]

some one write persistent transaction in MongoDB
http://debasishg.blogspot.com/2009/08/mongodb-for-akka-persistence.html

Any one know sample or how to structure mongodb schema for digital
offering.
Let say the site have several types of subscription pricing.
- $20 for Plan A
feature 1,2
- $40 for Plan B
feature 1,2,3,4
- $60 for Plan C
feature 1,2,3,4,5,6

--------------------------------------------------
Possible Schema design
- User
- Product
- Feature
- Invoice

However, I got stuck what is next