Is it a good idea to use MongoDB in .NET desktop application?
A:
It depends on what you want to store in a database.
According to Wikipedia;
MongoDB is designed for problems without heavy transactional requirements that aren't easily solved by traditional RDBMSs, including problems which require the database to span many servers.
There is a .NET driver available. And here is some information to help you getting started. But you should first ask yourself; what do you want to store and what are the further requirements. (support for Stored Procedures, Triggers, expected size, etc etc)
Rhapsody
2010-03-22 10:03:09
Well, MongoDB meets our requirements, but there are some issues:1. When a write occurs and the write command returns, we can not be 100% sure that from that moment in time on, all other processes will see the updated data only.2. MongoDB won’t make sure your data is on the hard drive immediately. As a result, you can lose data that you thought was already written if your server goes down in the period between writing and actual storing to the hard drive.
SHSE
2010-03-22 11:12:34
Ok, but I suppose you want to store statistics and such?If so, of course it's always important that you can be sure that the data inserted is actually saved, but if that issue is less important than speed...But personally; with the known issues I would search for better alternatives. For example a big one like Oracle or SQL Server or perhaps MySQL or SQLite. Can you give some more details about what and how much you want to store in the db?
Rhapsody
2010-03-22 11:48:35
MongoDB is fast, it is faster because it doesn't store the data on the hard drive immediately. It is also faster because it has eventual consistency instead of full consistency in a multi node configuration. It is all about trade offs. If you want/need full consistency and full durability, you should use Oracle (RAC) or Sql Server or ...
Theo
2010-03-22 12:24:25
Rhapsody: total objects count will be approximately 20 000.
SHSE
2010-03-22 13:50:49
Ok, well I have to agree with Theo. It's all about trade offs. Each DBMS (although MongoDB is slightly different) has its pros and cons. It's up to you what's most important. I think we can't help you any further because we simply don't know enough about the project. I'd suggest you build a small test environment to analyze the performance of several databases.
Rhapsody
2010-03-22 14:19:03
+2
A:
Mongo is meant to be run on a server with replication. It isn't really intended as a database for desktop applications (unless they're connecting to a database on a central server). There's a blog post on durability on the MongoDB blog, it's a common question.
When a write occurs and the write command returns, we can not be 100% sure that from that moment in time on, all other processes will see the updated data only.
In every driver, there should be an option to do a "safe" insert or update, which waits for a database response. I don't know which driver you're planning on using (there are a few for .NET, http://github.com/samus/mongodb-csharp is the most officially supported), but the driver doesn't offer a safe option, you can run the getLastError command to synchronize things manually.
MongoDB won’t make sure your data is on the hard drive immediately. As a result, you can lose data that you thought was already written if your server goes down in the period between writing and actual storing to the hard drive.
There is an fsync command, which you can run after every operation if you really want. Again, Mongo goes with the "safety in numbers" philosophy and encourages anyone running in production to have at least one slave for backup.
kristina
2010-03-22 22:06:49