Scroll to top
© 2020 OCTOCODE

Best database for your project


octocode - May 6, 2021 - 0 comments

When designing an application, it is very important to choose optimal solutions. If you think that  killing a fly with a cannon is not a good idea, then this post may interest you. This entry is  obviously not about fly extermination techniques. Today we will talk about databases. 

Key-value database 

This is a NoSQL type database. Everything is based on building key-value pairs. Very often, when  you see such a structure you may have an impression that it looks like an object in JavaScript. You  just need to set a unique key and assign a value to it. 

Interestingly, unlike other types of databases, in the case of key-value database, the data is stored in  RAM and not on the hard disk. This is one of the reasons why they are so fast. 

Of course, such databases do not give us the ability to perform any complex queries, JOINs, etc.  Everything is done on simple operations: GET data / SET data. They are ideal for caching  mechanisms, for example. 

Examples of such databases include: 

– Memcache 

– Redis 

Wide-column database 

Another example of a NoSQL type database. If the key-value database is no longer sufficient for  you, then you can think about using a wide column database. The difference between key-value and wide column is that we extend it by an extra dimension. Just like in a multidimensional array, here  we have access to multiple values (columns) under a single key (row key). 

You might think that this is enough to handle many cases of even creating relationships. However,  you have to take into account that unlike relational databases in this case we do not have any data  schema (column structure). Moreover, it is not possible to perform any JOINs. 

These types of databases work great for storing history, and when there is more emphasis on writing than reading/updating data. 

Examples of such databases are: 

– Cassandra 

– Hbase 

Document-oriented database 

JavaScript has already been mentioned. In this case, to illustrate the principle of operation, we can  say that we store a document in the database, which is a placeholder for key-value structure data  (e.g. JSON). 

Documents are not structured in any way and are not subject to any schema. However, they can be  grouped under the form of so-called collections. They are very convenient during development,  because they can evolve along with the application. 

They are ideal for creating collections of information such as catalogs or for creating Content  Management solutions (e.g. a blog system).

Examples of such databases are: 

– MongoDB 

– FireStore 

– DynamoDB 

Relational database 

This is most likely the type of database you associate with the most. In their structure, they are  divided into tables, rows and columns. The structure is governed by a well-defined schema. 

Relational databases are characterized by the fact that we can store parts of data in separate tables  (with specific structures) while maintaining relationships between them. This means that a row in  table A knows that it is complemented by data in table B. Of course, as long as it is designed in our  structure. Communication is done using SQL (Structured Query Language), which supports JOINs  that implement queries with relationships. 

They are ideal for most applications. However, they will not work well with unstructured data. 

They are very popular, and flagship examples are: 

– MySQL 

– PostgreSQL 

Graph database 

In a graph structure, data is represented by so-called nodes. Each node has its own properties. It can  also be connected to many other nodes, which allows us to create so-called graphs. These  connections are called edges. 

In the case of relational databases, we can also achieve a similar effect by creating so-called  relational tables (this is a table that has information about what rows from table A match what rows  from table B). However, in the case of graph databases, the performance of such queries is much  higher. 

Such a structure is ideal, for example, in recommender systems or when designing banking  solutions for detecting financial fraud. 

Examples of such databases are:  

– Neo4j 

– Amazon Neptune 

Search database 

At first glance, you might think that this type of database works very similarly to the document oriented databases discussed earlier. The difference lies, however, in the fact that during the search  the text from the whole document is analyzed. Additionally, an index is put on the search  conditions. 

Such databases, as the name suggests, are perfect for the functionality of searching in large amounts

of data. Their creators mainly focus on creating efficient algorithms that significantly speed up the  process of searching for relevant data. 

Examples of such databases are: 

– Solr 

– ElasticSearch 

– Meili Search 

Multi-Model database 

A very interesting approach to using databases in applications. Suppose we are developing an  application, but we don’t want to focus on complex structures. All we want to achieve is to pass  JSON and extract JSON. 

With help comes FaunaDB, which only requires us to provide information on how we want to  access our data using GraphQL. After uploading our GraphQL structure to FaunaDB, it will  automatically create collections in which we can store our data. 

In my opinion, it’s worth making friends with FaunaDB if you’re not setting your sights on a  database PhD. A perfect summary would be one of their slogans “Think data, not database  operations”. 

Summary 

A lot of information behind us. Let me know in the comments what you think about this post. You  can also throw in additional information from your side, as I 100% didn’t exhaust the topic in such a short post.

Related posts

Post a Comment

Your email address will not be published. Required fields are marked *