What does being schema-less mean for a NoSQL Datab

Question

Schemaless is a term that is currently floating around in the NoSql world.

1. What does this mean ?
2. I have a document with 3 properties today and I move to production with it, then what happens to my data when I need to add 2 more properties to my document?
3. Is this purely a migrations problem where I need to manage my data migration or can a NoSql database create as much friction as a RDBMS or make it easier in someway ?

Answer 1

Schema-less is a bit of a misnomer, it's better to think of it as:

• SQL = Schema enforced by a RDBMS on Write
• NoSQL = Partial Schema enforced by the DBMS on Write, PLUS schema fully enforced by the Application on Read (Externalised schema)

So while a supposed Schema-less NoSQL data-store will in theory allow you to store any data you like (typically key value pairs, in a document) without prior knowledge of the keys, or data types, it will be pointless unless you have some mechanism to retrieve and use the data. So essentially the schema is partially moved from the RDBMS into the application code. I say partially as you'll have added Indexes to document collections and or partitioned the data for performance, so the NoSQL DBMS will have a partial schema defined locally, and possibly enforced via Unique constraints.

As to adding additional attributes to a document/object in the store. Depending on how much padding is around the document (un-used space), in it's physical data block, adding a few more key value pairs to the documents may result in the document having to be physically moved to a larger contiguous block of storage, and the associated indexes re-built. If you plan to use the new keys in a frequently utilised query then you'll be wanting to also add a suitable new index, which will obviously require some physical storage, take a while to initially build and possibly lead you to ask the sysadmin to allocate more memory to the DBMS, to allow the new index(s) to be cached.

Answer 2

A bit late in the day but while searching on the topic again I found this article

http://tech.pro/tutorial/1189/basics-of-ravendb-nosql

Refer to section 3 in the article, I will quote it again for ease.

Adding and changing data models to RavenDB couldn't be simpler. Since it is a NoSQL database, it can handle additions and deletions to your models very simply. If a property is added to your class, it will be set to the default value of that type. If a property is deleted, then upon deserialization that value will be ignored. No more futzing with SQL Scripts.

This seems to be the logical answer for RavenDB.