Choosing a Database: SQL or NoSQL? – Building a Blog
Previously in Building a Blog: Building a Blog – Let’s Get Started!
With our first set of requirements defined, it is time to take a look at the very first one regarding the database. All the metadata of a blog post needs to be stored somewhere in some fashion. Therefore, choosing a database is something that needs some research. At the moment, there is basically a choice between two types of databases: SQL and NoSQL, but which one fits this project best?
What data am I working with?
Before we can decide which type of database to use, we need to know with what data we are working with. When thinking of a blog post, a couple properties come to mind:
- EndPoint: The URL you are visiting to view a post;
- Publish Date: The date a post is published;
- Category: To which category a post belongs;
- Tags: (Sets of) Words that give a brief insight in the content of the post;
- Blog Post: The actual content of the blog post.
Of course, there will be a lot more properties to come when adding more features to the project. However, we are now looking at blog metadata, so I want to put the focus on that. Nevertheless, it is important to keep in mind that the database will expand.
One more important thing to note here is that the blog post property will not contain the actual blog post. A blog post is often big and bulky with styling applied to it. I have thought of a different way to solve this problem. The blog post property will store the path to the file with the article. I will write my blog post in MarkDown and use other tools to convert the MarkDown file to display in the front-end. That way, I can store the file path in my database and use that to grab the actual file from the file system.
SQL vs NoSQL
I have heard many people say that SQL databases are for structured data and NoSQL for unstructured data. In a sense, that is certainly true, because you can store nearly everything and anything in a NoSQL database. There is no need for a detailed pre-planning of the data structure when implementing a NoSQL database. On the other hand, with a SQL database you need to plan out the data you will store and how that will fit into tables.
Another big question to ask when choosing between these two is: “Will there be any relationships between sets of data?”. The strength of SQL databases is in the relationships that you can define between tables. These relationships are usually either one-to-many or many-to-many. That allows you to query for all sorts of data that have some relation to one another. With NoSQL, the whole relation business does not apply as much. Hence, why people regard it as a solution for unstructured data.
Choosing a Database
So, what would I like to use for my project? I have looked at the SQL vs NoSQL, but even then choosing a database is quite difficult. However, I want to learn new things too. From what I can imagine, my data will not be very complex. I think it will primarily consist of the blog post metadata and that is about it. I am already very familiar with SQL databases, since I have used them for all my projects during college.
Therefore, I think I will go for a NoSQL database for this project. I want to control and host the database myself, so options like FireBase are already off the table. After some digging around, I have decided to go for MongoDB. It seems like the right tool to use, but I will know for certain when I actually start implementing it.
Data Types: Structured vs. Unstructured Data
Structured vs Unstructured Data – What is the difference?
Next up in Building a Blog: Getting Started with MongoDB
Good day! This post couldn’t be written any better! Reading this post reminds me of my old room mate! He always kept chatting about this. I will forward this post to him. Fairly certain he will have a good read. Thanks for sharing!
Hi, thank you for sharing your thoughts.
I’ve been facing this too, since I’m still planing and designing the development of a blog to keep practicing my coding skill.
Initially, I was thinking that my best option is to provide an SQL engine, since maybe the 70% of my components are based on relationships (login, accounts, profiles, etc.). But at long term, mostly of the data traffic will turn to the posts’ content, therefore, NoSQL seems to be the best options… but!!
Based on your idea of “save and read” the file’s path, I’m thinking that I can keep all my model relations in an SQL engine, including some information about the post, e.g. title, published date, tags, and unique Id of the post, and leave the heavy-post-data (body, comments, etc…) to the NoSQL database.
Glad I could help! In the end, it all depends on your own requirements and using the best of both worlds is sometimes the better option. 🙂