Depending how rigorously we design the database back-end, maintenance as such may be superfluous, but in this application there's one situation where we may reasonably want an additional "tag maintenance" function: if we ever want to mass-replace one tag with another, ala my previous example of merging all "mileage" tags with "fitness". The app can function without that, but it can't function without basic CRUD procedures, so let's look at those first.
Create: On submission of a new entry, we'll INSERT the entry record, then explode() the tags field and loop, writing a record relating entry ID number to tag, for each unique tag in the entry. Until now, we had no need to retrieve the entry ID after creating a new entry. We just let the MySQL engine (not the app) auto-number the ID field. Fortunately PHP does provide a mechanism to retrieve the most recent auto-number assignment: the mysql_insert_id() function. This would be unreliable in a multi-user application, and we would have to start thinking about wrapping entry-creation and ID retrieval in a transaction, but for a one-man blog this isn't a serious concern.
Read: We could keep a redundant comma-separated list of tags as a field in the entries table, but we don't gain much performance by doing so, because everywhere we use that list, we have to explode() it for formatting into HTML link tags anyway. So we may as well read the entry-tags table here too, and drop the tags column from the entry table in accordance with relational normalization.
Update: The easiest way to handle this would be to summarily DELETE FROM entry-tags WHERE entry-id="whatever"; and then re-INSERT new entry tags. We might or might not gain some performance by comparing the previous tag-list (perhaps as an embedded hidden form field) with the updated record.
Delete: This is where we see the most simplification against the former design direction, where we maintained an entry table and a disconnected tags table without relating them through the entry-tags join table. We DELETE the entry-tags associated with the entry and then SELECT COUNT in tags table for each tag. If COUNT is zero we delete that entry from the tags table too. If we don't mind a mild database hit on every load of a tag-stats widget, we can even do away with a distinct tags table; if the entry-tags table is indexed properly this shouldn't be a big operation, even in a multi-user app up to dozens and perhaps hundreds of users. (When we start talking thousands of users, I'd lean toward stricter normalization, but with thousands of users I'd also have a mandate and support to test performance both ways and implement the better-performing approach.)