Redesigning the 'blogs' program

Over the past few weeks, I've spent a fair bit of time with my 'blogs database' program and have been thinking about various improvements. Roughly speaking, the program (as like many others) can be split into two: the part that deals with entering/storing the blog entries and the part that deals with creating reports about the entries. Whilst the first part was handled well, the second part was totally lacking. The ideas that I've had, such as the 'this day in the blog history' don't fit into the paradigm established by the program, so I realised that I would have to redesign it and rewrite parts (as well as adding new parts).

Yesterday evening, while walking the dog, I was thinking some more and realised that I would like several different functions to output a list of blogs, each showing different data. This would mean using the multiple document interface (MDI) and displaying the same form several times. How would each instance of the form know what to display? I was thinking originally in terms of a temporary table that would hold the chosen data, but I quickly realised that this would not be sufficient. 

In Priority, there is a mechanism called 'link' that creates a new copy of a table; data is inserted into this copy and then displayed. Eventually the copied table is destroyed. For a few moments I thought about creating new tables then dropping them, but after a while I realised that I could greatly simplify this.  I added to the temporary table a new field, 'instance' that would be part of the primary key; each query would get a unique instance and store its data (entries) along with that instance. The form that displays the data would be sent the instance number and so would retrieve the correct data. When the form closes, it deletes the data from the temporary table and frees the instance number for further use. 

I worked all of this out last night and today I was able to spend a few hours working on the program and changing it around. Some parts - for example, choosing tags for an entry - have remained the same, whereas other parts have been slightly modified. The whole 'instances' idea worked perfectly. Using the same idea for tags is a bit more difficult as one query (unused tags) needs to display only tags whereas another query (entries per tag) needs to display both the tags and their counts. After fiddling around a little, I figured out how to handle this.

Another idea for a report was taking one popular tag (e.g. programming) and seeing how many times different tags have been paired with this tag. Then I could retrieve the entries that have the chosen combination of tags and show them in the the 'show entries' form. Expanding the program is much easier now.