In this chapter, we're going to review an emerging database paradigm that totally remodels the structure of data, NoSQL databases.
In brief, I will cover the following topics:
- A historical context about NoSQL databases and their role in current development
- Available offers in this area and their main advantages and disadvantages
- The architectural model followed by the distinct flavors of NoSQL databases
- MongoDB as the NoSQL database of choice and its foundations and main features
- CRUD operations in MongoDB
- We'll end with a review on how to integrate and use MongoDB from Visual Studio and manage CRUD operations within the IDE
In the last few years, companies such as Google, eBay, Facebook, Bosch, Forbes, LinkedIn, Marriot, PayPal, Ryan Air, Symantec, or Yammer have solutions that use these databases, to name just a few.
If we take a look at the statistics published by the specialized site DB-Engines, results showing utilization rates are pretty clear, where some no-SQL databases appear among the top 10 in use today (especially MongoDB):
Therefore, there's a growing trend around these database systems, and it's especially meaningful that MongoDb shows up in the fourth position. The first five companies mentioned earlier use MongoDb for different purposes and scenarios.
Until the second half of the nineties, nobody would doubt that SQL and Relational Model databases were the de facto standard and a large majority of commercial implementations in use those days were based on this assumption.
Historical examples are IBM, Oracle, SQL Server, Watcom, Gupta SQLBase, and so on. However, with time, some voices started to claim against what was already called impedance mismatch, the different representations of data and source code that happen when programming in object-oriented languages to these databases.
This is something that's clearly revealed when objects or class definitions have to be mapped in some fashion to databases (either tables or relational schemas).
Other problems arose from the different data types supported by both worlds, especially in scalar types and their operation semantics (for example, collations for different string interpretations), although OOP languages only consider this aspect in sort routines and strings are not treated as fixed, such as in RDBMS systems.
Besides, there were structural and integrity differences between both, not to mention other operational dissimilarities in manipulation and transactions.
So, new proposals were made about object-oriented databases, in which information would be stored in a such a way that it becomes simple and straightforward to make the correspondence between the two worlds. However, these proposals didn't reach the commercial arena, and actually, only some niche areas, such as engineering and spatial databases, high energy physics, some telecommunications projects, and molecular biology solutions, were actually using this approach.
One of the problems, in the words of Martin Fowler, was that people were doing a lot of integration in classical databases, making it really hard to change this paradigm.