I was supposed to settle on a project name, but none of the things I came up with are making me excited, so I'm just going to keep thinking about this blog engine as "my-as-yet-unnamed-blog-engine-and-by-the-way-I-hate-the-word-blog".

But that doesn't have to mean stalled feature development. For my next trick I want to build in a "tag" feature. I think the easy approach will be to explode() the comma-separated "tags" list on entry submission, looping through to add any novel terms to the tags table. The tags table supplies a widget to filter entries by tag; and of course every entry-view would link related tags to that filter too. Nothing dramatic, and especially no "tag clouds". *retch*

Knowing me I'll eventually want to be able to mass-update tags. For example let's say I tag all my fitness-training adventures "running", but then later I decide I want to lump those entries in with other forms of body maintenance like "sit-ups" and "workout" and "yoga", all under a new tag/heading of "exercise". This is not as easy as it sounds, unless you roll with a fully normalized relational database structure. Then it's real easy to update with raw SQL commands, but the amount of PHP coding required to provide a web interface increases drastically. Like, to the point that I would never get around to writing that interface.

So, we will have a "tags" table. And instead of a fully normalized join table relating tags to entries, we wll have an arguably storage-inefficient "tags" column in the "entries" table. And I'll figure out some computationally-inefficient tag-merging and tag-renaming mechanisms when the need arises.

I read one tutorial where the tutor even did away with the tags table... anywhere he wanted to bust out a list of tags, he parsed the tags column row by row into an array, and then programatically "collapsed" that array to unique values. Seems like a horrific waste of computation, and the blog industry doesn't need to be any more egregious a waste than it already is.