Real life MongoDB experiences

February 28, 2017 | by Rodolfo Ortiz

In App development, developers

Here in Definity First we are mostly a .NET shop. However, that doesn’t mean we’re married to .NET.  Our approach is picking the technology that best suits the needs of the project. 

Things I learned from the world of NoSQL databases

Right now I’m working on a project that uses MongoDB.  It was chosen because the application needs to support a wide range of schemas which are not predefined at compile time. The alternative, a RDBMS (relational database management system) was not the best option since it needs a defined schema ahead of time.

Save the schema in your database

Isn’t being schema-less the whole point of NoSQL? Be that as it may, you still need to know how data is organized once it’s in the database. In other words, when you access it from your repository, it’s important to know the data type of the columns and other information that is a given in a RDBMS, like a column being not null. You should store this metadata in MongoDB too.

MongoDB experiences that let you know how this tool works

Try to make your code schema less too

What’s the point of using a versatile design at the database level (by using NoSQL) if you’re not following the same pattern in your application? You should aim at making your C# code versatile too.

Duplicate data

Yes, you’ll probably have multiple copies of the documents. For this, I recommend the book “MongoDB Applied Design Patterns: Practical Use Cases with the Leading NoSQL Database”. This book provides examples of different ways to store data.

Spend time designing

Parts of your application may not have a predefined schema, but others will. The fact that using MongoDB is really simple and that you can start saving information without a schema doesn’t mean you should follow this pattern in all your application. Carefully design how you plan to store your data.