The concept of NoSQL databases has been around for a while, but there still are quite a few misunderstandings regarding the topic of relational SQL vs NoSQL databases. In this post, I’d like to clarify the most common misconceptions and discuss the primary use cases for each of them.
Are NoSQL databases really schemaless?
A quick note before we start: the notion of NoSQL refers to 4 different types of databases: Document-Oriented, Column-Oriented, Key-Value stores, and Graph DBs. In this post, I talk about Document-Oriented databases primarily. I refer to them as NoSQL for the sake of brevity but keep in mind the term itself has a more broad scope.
Alright, so are NoSQL databases really schemaless? Let’s take an example. Let’s say we have a document collection named Customers with the following data inside:
{ Id: 1, Name: “John Doe” },
{ Id: 2, Name: “Bob Smith” }
Because of the collection’s schemaless nature, nothing prevents us from adding another document, like this:
{ Id: 1, Name: “John Doe” },
{ Id: 2, Name: “Bob Smith” },
{ Id: 3, FirstName: “Alice”, LastName: “Christopher” }
Now, let’s say we have a method that looks for customers given a particular name:
public class CustomerRepository
{
public IReadOnlyList<Customer> Find(string name)
{
return _collection.Find(x => x.Name == name).ToList();
}
}
What would happen if we add Alice Christopher to the collection the way we did previously? Would the Find method find her? Surely, not. The repository class implicitly relies on the collection schema and require all customers to have the Name property in order to be detected. In this scenario, we have to adjust the Find method so that it would start looking at both Name and FirstName/LastName properties.
While NoSQL databases are technically schemaless meaning that they allow us to store documents in any shape we want, the notion of schema itself doesn’t vanish from our domain model. Schemaless databases just shift the responsibility to maintain the schema to us, developers.
To read more click here.