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 the 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 database 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 might have some relation to one another. With NoSQL, the whole relation business does not apply as much. Hence, why people regard it as the 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 database, 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.
Resources
Data Types: Structured vs. Unstructured Data
Structured vs Unstructured Data - What's the Difference?
Top comments (0)