Top 10 Latvia-Based Software Development Companies
Learn about Latvia's top software development companies and their innovative solutions in our latest article. Discover how these tech leaders can help elevate your business.
Creating a new project includes choosing the right database to store your data. Many developers that I know choose the relational database by default from the beginning. But is it the best decision? Of course, it depends on many factors. In this article, I would like to introduce you to other types of databases to make your choices easier and help you be prepared in your future endeavors.
The type of your database is not the only topic to consider. There are many other issues to think about, e.g., how many active users the application may have? Do you need strong consistency everywhere? Will the eventual consistency suffice in some cases? There are so many questions without straightforward answers as “the more you get into it, the more complicated it becomes.” So, please, make note that this article is focused only on database types.
Take a cup of coffee and enjoy this reading.
At the beginning, it is good to know that there are two main types of databases: relational (SQL) and non-relational (NoSQL).
There is one more type apart from the two mentioned above, namely an in-memory database. It cannot be classified neither as relational nor non-relational because it relates to where the data is physically stored. Every database could be stored on a disk or in memory.
In my opinion, it is the most popular type of database. It works well with structural data where you want to keep relations between the records. The database structure is described in a schema.
The main advantages regard transactions (they help to ensure data integrity and follow the ACID rules) and the ability to handle lots of complex queries.
It is useful for keeping data that does not change structurally very often and that you need to store permanently, for example:
Amazon Aurora, Microsoft Azure SQL Database, PostgreSQL, MySQL.
Relational databases are insufficient for many new applications and you need to have more than one database. In the next part of the article, I will focus on the non-relational databases.
It stores each data value with a unique key. It means that data is accessed by a single key, just like it is done in a hash map. In contrast to relational databases, it neither enforces the scheme nor relationships between records. Most of these databases do not ordinarily support update operations. To modify data, you have to overwrite the whole existing set.
It is useful for data that you want to read/write fast (but do not update very often):
Memcached, Amazon DynamoDB, Azure Cosmos DB, Redis.
It stores collections of documents. Every document contains fields with data, which may be simple values or complex elements, like lists or child collections. It is important to know that every document may have a different structure, even if they represent the same thing (each document is unique and evolves over time). For example, the first customer document contains less info than the second:
{
"FirstName": "John",
"LastName": "Fake",
"Motorcycles:" [
{
"Model": "BMW",
"Year": 2020
}
]
}
{
"FirstName": "Alex",
"LastName": "Nolastname",
"Age": 15,
"Address": {
"Country": "Poland",
"City": "Somewhere"
},
"Motorcycles:" [
{
"Model": "BMW",
"Year": 2020
}
]
}
It is useful for data that require a flexible schema for fast processing:
Amazon DocumentDB, Azure Cosmos DB, MongoDB, Redis.
It uses a graph structure and is built of two elements: nodes and edges. Nodes are analogous to table rows or JSON documents. Edges are relationships between the nodes – they are as important as nodes. Both of them can have properties. Moreover, edges can have a defined direction of a relationship.
It is useful when your data is similar to a graph, i.e., relationships between data items are dynamic and change over time. Furthermore, it is a good choice for when a business or technical team need to understand relationships within their data. Some prominent examples include:
Amazon Neptune, Neo4j, ArangoDB, Titan.
It stores data organized by time. Typically, it accumulates enormous amounts of data in real-time. It is most often used to save data, though updating is very rare. Generally, a timestamp is used as the primary key and/or sorting data. Some databases allow defining tags to be included as additional information, like data origin or type.
It is useful to store small amounts of data appended sequentially in chronological order, for example in:
Azure Time Series Insights, Amazon Timestream, InfluxDB.
It provides an immutable, transparent, and cryptographically verifiable transaction log owned by a central authority. – Amazon’s QLDB Overview
Let’s shortly explain every keyword in the above quotation:
It is useful to store accurate history, e.g., logging sequenced entry of every data change, as in:
Amazon QLDB
There is no simple answer to the question posed in the title of this article. The only way to choose the right database is to learn more about your data. Answer the question: “What kind of data does your application generate?”, and you will be able to make the right choices.
Furthermore, you should know the business requirements and the application domain very well. You need to know how you will use the data, what queries you will send to the database, how many times you will keep, read, update, or delete your data. All of these things matter, but not all developers pay enough attention to these areas.
Please think about your data in the application you develop to improve/create better software. Overall, I hope your will get to know your data well enough to store it in a place where it will be happy.
Read more:
A few tricks to speed up your JavaScript application
Ways to increase your Rails performance
Facts and myths about cooperating with external software development partner