NoSQL because we made that Prequel

by Andy for Blog
NoSQL because we made that Prequel

A SQL database is a database that has relational data. For example Phil is in the database table Person, Phil has a car, Phil’s car is stored in the database table car. We know that Phil’s car belongs to Phil because we link the records together using a foreign key. This is called a relation. Hence relational database. NoSQL differs in the sent that data is not stored in a relational way. NoSQL has many different forms each suited to different needs, these are:

Document Databases: such as MongoDB, used to store JSON like objects.
Wide-Column stores: such as HBase, commonly used for big analysis, because of it’s ability to hold millions of columns.
Key-Value stores: such as Redis, used to store key and value pairs.
Graph stores: such as neo4j, a graph is composed of a node and a relationship.

Both Amazon and Google offer different services for these types of databases on their hosted platforms, Microsoft not so much as seen as they developed a lot of SQL.

NoSQL is in many ways the reverse of SQL, in SQL you’d be like I need to model this entity, this entity and this entity and they link by xyz. But in a NoSQL database it’s more of a case of what data am I going to be pulling back, so you’d design your queries and then base your data models on them.

This is because there is less structure to your data in a NoSQL database, although your application needs to be aware of the structure of the data that it would be receiving hence the reverse approach to SQL.

Without the need for a database scheme, data modelling is very important in NoSQL. You need to answer these questions, among others:
What kind of data am I going to store in a collection (table)?
How will nested data be structured?
What attributes do I need if any for each model?

There are many different strategies you can use to answer this question a few are:
Denormilisation – NoSql data duplication across rows and tables is okay. So instead of saving keys of referenced data, you can embed duplicated data itself in each row. As it is faster for you to get all the data as there are no joining of tables.

Application side joins – Sometimes duplicated data is a nuisance when updating frequently, in this case it may be a better idea to store keys instead of data itself and then join the data inside the application later when needed.

An example database model when sending a text
“sender”: “Dave”,
“type”: “text”,
“content”: “Test Text”,
“channel”: “1_12”,


In conclusion, hopefully this brief introduction into NoSQL has helped you in some way. As with all technology it depends on your needs and how you are going to use it. For example if you wanted to keep records of an Internet of things device that was sending you a lot of data, regularly I would use a NoSQL, but if I was creating a structured database where everything was in some way linked then I would use a regular SQL.

Thanks for reading,




Constant or ReadOnly?
Prev post A Brief History of Cryptography

Nowadays, most of us take cryptography for granted. In every email we send, online purchase…

Constant or ReadOnly?
Next post Constant or ReadOnly?

ReadOnly properties and constant fields may seem to achieve the same results. However, there are many…