Hi
what do you mean by "negative comment about using MongoDB in a transaction database"?
who wrote this? innovators and leaders? or "more-of-the-same" thinkers?
to the point you are asking:
it depends on what you want to model.
if your app collects all the data composes all the data it needs to save and sends it in one document - the document will either succeed or fail atomically.
that's what the best transactional system can give you.
if, on the other hand you are thinking of doing stuff like splitting the data into several tables and having the success of all depend on the failure of any/ some - than you can't rely on the mongoDB to do that for you. you should do that in your app.
BUT (and that's a big but) you should ask yourself if you need to split the data or you simply have not fully adopted the schemaless way of thinking.
try to play this mind game:
you only have mongoDB as a db technology. mongoDB supports only one collection, You have to serialize all your data into it. what you can't serialize into it - will be lost.
how much data have you lost?
If you did (and i don't see many reasons why), is any of it important?
if you have not lost any data or have not lost any important data - you have not only proved that mongodb would be suitable but you have also got to a good start with schema design.
in real life the schema might be composed of several collections - but as a mind game it will open your mind to new and exciting things.
Have fun,
Daniel
On Thursday, February 28, 2013 4:25:50 AM UTC+2, Eko Suprapto Wibowo wrote:
Dear community,
I am new in MongoDB, but recently already create a POC application in desktop C#.NET that do CRUD on MongoDB database hosted at MongoHQ.
Realizing that my database can be safely stored in Cloud, I was thinking to employ this into my new Point of Sales application, that will cover a great range of POS installation anywhere.
But, having read some negative comment about using MongoDB in a transaction database, I was thinking of having another MySQL in local POS installation, with the MongoHQ database in cloud acted as a central database. Roughly the MySQL will serve as the database that will handle day to day transaction. While the MongoHQ central database will serve as the synchronization database to other POS branches installation. This way, each local POS will have a synchrohize process that will stored its database into MongoHQ.
Do you think this design good enough to employ?
Thanks,
Eko