NoSQL: life without a schema

Preamble

​​

NoSql is not a replacement for SQL databases but is a valid alternative for many situations where standard SQL is not the best approach for storing your data.

Since we were taught that whenever you need to store data in a “data warehouse” and query that data for extraction, SQL is the best solution, you only have to decide which SQL Engine to use and the game is over.

In 2012 this suggestion was wrong, I mean that you can no longer assume that SQL is the “only way” to store data, but you should know that there are other alternatives and they are called NO SQL. Under this term, we have different storage mechanisms that are not based on SQL, and in .NET we have an exceptional product called RavenDB (you can find a really good introduction to RavenDb in the Mauro blog).

The first big difference with standard SQL is the absence of a schema

One of the most annoying limitations of SQL Server is the need to specify the exact format of the data you want to store in your storage. This is necessary for many good reasons, but there are situations where you really do not care about it, especially if your software is largely based on the OOP concept. Suppose you have this object

1: class player

2: {

3: public String Name { get; set; }

4:

5: public DateTime RegistrationDate { get; set; }

6:

7: public Int32 Age { get; set; }

8: }

For a moment there is no concern that this object is poorly encapsulated (it has a public method of obtaining and installing it), but only focused on the need to “store” this object somewhere. If you use a standard SQL repository, the first thing you need to do is to create a table, then define the columns, define the maximum length for the Name column, and finally select the ORM to use or create a dedicated data layer, and finally, you can save the object.

If you are working with a crow, this is the only code that you need

1: var store = new DocumentStore { Url = "http://localhost:8080" };

2: store.Initialize();

3: using (var session = store.OpenSession())

4: {

5: var player = new Player

6: {

7: Age = 30,

8: RegistrationDate = DateTime.Now,

9: Name = "Alkampfer",

10: };

11: session.Store(player);

12: session.SaveChanges();

13: }

The server simply takes the object and saves it.

In order to save an object to the data warehouse only two functions are needed: “Save” to tell the repository the object you want to save, and “SaveChanges”, which actually perform the saving.

What do you get with this simple code fragment? Just go to the standard browser at the server address and you should see the contents of the database.

Database Contents After Simple Object Insertion

In Figure, you can see the contents of the database crow, it contains a player and a small 1 next to the object is Id, which Raven uses internally to uniquely identify this object. Another object, called Sys Doc Hilo / Players, takes care of generating an identifier for the Players object with the Hilo algorithm.

This is all, there is no need to define the scheme, there is no need to have a special Id property or any other requirement to make the object compatible with the repository, just call the Store method for any .NET object, and your object is in the database, Period!

 Steven Lott | NoSQL doesn’t mean No Schema

Enteros

About Enteros

Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of RDBMS, NoSQL, and machine learning database platforms.