It didn’t seem very difficult to break the project down into manageable chunks; Nicks lecture advised as such and it seemed to be a very good way forward. It seemed that the steps translated to the following:-

1. Produce a command line application to read and write the ID3 tags of a single file as a command line argument.
2. Design and construct a database to hold this information and a way of adding multiple sets of data to it in a fast fashion.
3. Create the architechture to enable searching and editing of data in the database, along with updating the files. Statistics.
4. Wrap a GUI around all of it to make it usable and friendly for the end user.

While this is a good enough list I paid careful attention in my thoughts to number two, as I’m sure other people would be doing after recent DB11 work. SQL is very powerful, and the potential to leverage this power to produce both an extremely functional and fast app are immense. It is however worth noting that going to and fro from hundreds of MP3 files will be very slow. This brought my thoughts firmly to database design, and devloping a good schema.

Each file needs to have an id, and be recorded in the db with it’s id, path and filename. This means all the searches and retrieval of data after the initial building of the index can be done solely with the database, unless new files or added or the user updates tags. So, thats day to day speed of the system, praise SQL.

Thats not the end by far though. What if the files get out of sync with the db? You might delete a song outside of the app, yu might change the filename outside of the app. This will leave “dead” items in the db, so a simple track needs to be arranged that merely checks for the existance of files, rather than reading them, and compares this with the db. Files recorded in the db that don’t really exist (or have had their names changed) need to have their entries purged, and new files need to be added without the need to re-scan the whole collection.

Although a lot of this comes later in the project, it seems very clear to me that a good database design will allow the database to take the strain of the main searching and tagging work, allowing the files to only be operated on when strictly necesary, thereby making the program much faster for the user and ensuring we only have to put in a small ammount of concentrated effort to make it so.