There's a strange satisfaction that occurs when you re-visit an old application's design through the process of re-factoring code or re-working a database design. In the case of the transition of Mapraider 1.0 to version 2, there were many opportunities for improvement in the database design. Particularly in cases where quick-fixes had been applied to the original structure during the past few years.
This Entity Relationship Diagram (basically the structure of the site's database) may look like a jumbled mess, but in reality it's elegant and far superior to the existing database:
One of the biggest challenges in the database for Mapraider 2.0 is how to add support for Map Packs — a collection of 2 or more individual maps — in a way that was scaleable, fit into the UI seamlessly and made sense without duplicating a lot of information. Analyzing the logic/rules behind map packs seems simple enough, but when you start to factor in particular functional requirements, it can get hairy very quickly.
Map packs are treated as individual maps on the current version of Mapraider as single maps. It works, but it's a somewhat of a duct-tape fix since only one author can actually be assigned to the map and the others mentioned in the description. If all authors are members of the site, this makes it impossible for them to each get reporting on the map, or be added to a user's favorite authors list.
It is also not uncommon for pack authors to release their individual maps separately once the pack has been out for a period of time. In this instance, we end up with each map in the database twice, but completely unrelated on the current version of the site: once mentioned on the map pack page and once on the map's own detail page.
One of the requirements for 2.0 is to have a link between packs and individual releases if one or the other exists. The debate then becomes whether to store each map in the pack as stand-alone map entries (leaving download links empty until it is released individually) that are combined into a "pack" on the fly, or store the pack as a summary that links to individual releases map detail pages only if they exist.
There are a number of similar challenges when dealing with map packs, but I believe I've come up with an elegant solution (the details of which I won't reveal just yet :). In any case, the database design for Mapraider 2.0 is quickly arriving at a point where it will solve the map pack conundrum and facilitate many other new features and fixes.