data base paradigms part1

 

Hey, there let’s talk about an interesting topic in development domain, Data bases!

  It’s crucial to understand the concept of each type and of course when and how to use it. Because each concept can serve usage better than other. And you should know which tool to use.

Let’s start our list with simplest to  more complex one .

1-key-value:

It includes redis, MemCach …it’s structured like object (in java script) or dictionary (in python).composed of couples of unique keys that are pointed to a value.

The data is, in general, stored in machine memory .So you guessed😁, it size must limited and very small. But in the other hand retrieving the data is much faster. It doesn’t perform queries or join so options are limited. It’s mostly used for caching data .twitter and github uses redis for example.

2-wide column:

Since the previous one is very limited, we tried to add second dimension to it. Each key will be pointed to a column not a single value. It has no defined schema so it can handle unstructured data. Also you can’t make joins and it’s less limited than the key-value. Much easier to scale up and replicate data across multiple nodes. It’s used by Netflix to store a history of different shows you have watched. Very useful when having frequent writes but less read and update.

3-document orient:

It’s a generally purpose data base. You may heard of firestore or mongo db ?

Here we have document and each one is a container for key value pair. The doc are grouped together in collection. And of course doc doesn’t require a schema. Collection can be easily indexed into logical hierarchy. It’s very easy to use. It’s generally purpose more than any other one. A lot of developers prefer it for small apps , iot and games. But not ideal for graphs or a data need to be joint or frequently updated!  It became a mess.

4-relational:

As known as SQL. Very known one like MySQL, postegress … the language used here is SQL to manipulate the data base. The concept is about creating tables with rows and columns and the most interesting part the relations in-between.

We generally represent real world object by entity or table. And each table contain its unique primary key . We can make relations using foreign keys that reference other table’s attributes. Well, it requires a schema for sure, but it’s ideal for most of apps except the non-structured ones.

part2

 now try to understand this well because in the next article we will go in depth💪😎