Database design
Ok, so starting the development first step (at least for me) is quite obvious.
Think about the data handling and data storage.
As the primary project goal is learning PHP, this step is somewhat small, but still it’s needed.
My first thought some time ago today was „What tables and which fields do you need?“
So I furiously started scribbling on a piece of paper and soon realised what was drawn on the paper is not what I need.
It was a great mess trying to get all the stuff that is possible in the design, instead I should start low and focus on what I really need in order to get the base functionalities.
Well, what is the baseline in terms of functionality a blog needs? Obviously the blog-posts (or articles), so one table for the articles might be a good start.
Of course that table needs some fields. Again the question, what is the baseline? That’s an easy one – Headline and Content should do the trick, plus a unique id for internal useage.
Ok, that’s a little bit to basic, so add a creation date, author (maybe sometime I want to invite someone to participate on the blog, who knows…)
More advanced, sometimes there is not enough time to finish a new post straight, so maybe a status for „draft/published“ should be available, so add that too.
Last there is a feature I want for the blog that could should be taken into account too:
Multilanguage support. So for now there will be two fields for the headline (german and englisch) and also two fields for the content.
Yes, this is something that definitely should be refactored and yes I shouldn’t wait too long before refactoring as this is ugly, hardcoded and not easily extensible, but for today I’ll leave it just like it is.
Now we can display articles, but wait, maybe there should be a refinement in favor of organizing several blog-posts together. Of course I’m talking about categories, so add another table for the categories. This is a very simple table, as it just needs three fields: Category-Name, Category-Id and advanced a Parent-Category-Id.
Not much of a fuzz, so what’s next?
Do you need comments? Well, I don’t really need them, but it would be rather nice to have the feature, so there is table number three.
What is the baseline? Of course an unique id (like quite always). Next a Name (single field, just a nickname maybe?) and the comment itself.
I’d like to know if a comment is old or new, so creation date is a must! And sometimes I might want to contact the user who left a comment, so add a field where an emailaddress can be added.
Maybe said user want’s to share his own page/blog with me (and obviously the world), so why not adding a field for website?
Ok, looking sweet and easy so far – still we need a place where we can define in which categories each article is contained; same for the comments.
This leaves me with a basic db design displayed in the following pic.
Like said, I have to refactor the multilanguage part of the articles table. I’m already thinking about the possible solutions (and which might be the best or at least most suitable for my needs/wishes).
So long.