NoSQL: A Life Without Schema

nosql is not a replacemente for sql databases, but it is a valid alternative for a lot of situations where standard sql is not the best approach to store your data. since we were taught that whenever you need to store data on a “data store” and you need to query that data for retrieval, sql is the best solution, you have only to decide what sql engine to use and the game is done.

in 2012 this sentence has proven wrong, what i mean is that is not possible to assume anymore that sql is the “only way to go” to store data; but you should be aware that other alternatives exists and it is called no sql. under this term we have various storage engines 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 mauro’s blog ).

the first big difference with standard sql is being schemaless. one of the most annoying restriction of sql server is the need to specify exactly the format of the data you want to store inside your storage. this is needed for a lot of good reason, but there are situation when you really does not care about it, especially if your software is heavily based on oop concepts. 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 do not care about the fact that this object is not well encapsulated (it has public getter and setter) but focus only on the need to “store” this object somewhere . if you use a standard sql storage, first of all you need to create a table, then define columns, decide maximum length for the name column and finally decide an orm to use or build a dedicate data layer and finally you can save the object.

if you work with raven, this is the only code 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: }

i simply created a documentstore based on a local server, opened a session and saved an object, i did not defined anything on the server, i did not need to have an orm, the server simply takes the object and save it, period!

i liked very much this approach because

i needed to save an object to a data storage and everything i need is just a two function all, store to tell the storage the object i want to save and savechanges that actually do the save.

what i got with this simple snippet of code? just browse with a standard browser to the address of the server and you should see the content of the database.

figure 1: content of the database after insertion of a simple object

from figure 1 you can see content of the raven database, it contains a player and the little 1 beside the object is the id that raven uses internally to uniquely identify that object. the other object called sys doc hilo/players takes care of id generation for players object with an hilo algorithm.

that’s all folks, no need to define schema, no need to have special id property or any other requirement to make the object compatible with the store, just call store method on whatever .net object and your object is inside the database, period!.

this is only a scratch of the many functionalities of ravendb , more to come in my blog and in mauro’s one .

gian maria.

source: http://www.codewrecks.com/blog/index.php/2012/02/04/nosql-and-a-life-without-schema/