oldSTAGER No.100
October/November 2006

 

Home


Published Novels

Nearest FarAway Place

Chapter 1

Reader Reviews

Prototype Covers

Location Photos

Panglossian

Prologue/Chapter 1

Golgonooza Review

Reader Reviews

Cover Photo Shoot

Acknowledgements

Schoolfrenz

The Shields Gazette

Readers' Review

Evening Gazette

Prologue/Chapter 1

Photos (Marsden)
Photos (Bill Quay)

Geograph (Marsden)

Geograph (Bill Quay)
Thalamorph
Chapter 0/Chapter 1
Photos (Aoraki)
Photos (Tekapo)
Look Magazine
Tribune

Buy on the Internet


Novels In-Progress

Odd Jobs

Downfall or Destiny?


Panglossian Books

Contact Details


Magazine Articles
oldSTAGER

Author Reference Links

Marsden Grotto

Bill Quay

millihelen
Geograph (Marsden)
Geograph (Bricklayers)

Author Maintained  Sites

Barclay Reunions

Cathy Logan

Pegularity

Table-Top Rallying

Tom Hood Reunions


Archival Revival

Ever since I gave up the day job there's a project I've been desperate to tackle – computerisation of my rally archives. With a September devoid of competition I finally made a start.

For almost 40 years, rallying has been a large part of my life confirmed by the numerous boxes of paperwork, photographs and press cuttings that had been gathering dust in the loft. Why did I hoard all this stuff? Two reasons. First, I thought it would be potentially advantageous to look back on a previous event's paperwork if I did the event again – particularly items like route cards. Second, it was a substitute for a diary I had never got around to writing.

The rest of this article is technically biased, but since most navigators seem to be computer experts these days, take a deep breathe and continue.

There were two basic types of data I wanted to store electronically: statistics about an event, and various documents such as photographs, press cuttings and route cards.

I used to record statistics in a spreadsheet, but since I wanted a more flexible way of organising the data, a proper database was the only route. Which database to use was an easy choice: MySQL. It's free, versatile and many web hosting companies make it available to their clients' websites.

A database on its own is not much use unless you have a convenient means of talking to it. This led me to choose a scripting language I could also use to access the database from a browser. Another easy choice: PHP. Again PHP is free and is the language of choice by hosting companies. There's also a handy third-party PHP tool called MyAdmin. This provides a complete visual interface to MySQL which makes designing and maintaining your database a breeze. However, if you want to craft your own browser-based maintenance and display screens you will need to get your hands dirty with PHP web page programming.

A crucial decision for the database is what key to use. I recommend using the start date of an event, since the primary sequence of accessing data will usually be in chronological order. Furthermore, the standard way of storing a date in MySQL is in the format YYYY-MM-DD and, as you will see later, this format will be preferred when dealing with the storage of documents.

What other basic data you store is according to taste. You will probably want the event name, your overall position, driver or navigator, and car details. I also chose to store trivia such as organising club, number of starters, maps used, length of event etc.

A formal database is, however, not strictly necessary. You could hold the basic data for each event in a simple text file, or better, set up a template in Word; although searching and displaying data from such sources will not be so easy to accomplish.

Nowadays much of an event's paperwork will be available as electronic files in .doc, .pdf or .xls format. Older items, and photographs and press cuttings need to be scanned if you want a digital version. The ideal scanned format for documents will depend upon many factors, suffice to say that jpeg is best for photographs, and use reduced-to black and white gifs for press cuttings.

I don't recommend storing digital files inherently in the database, that will make it too unwieldy; instead, keep them as separate files in a "resources" directory. Significant naming of the files is important and needs careful planning.

Here's an example file name: 2006-10-01_RA_CO_PR_MN_Oct-5.gif

The event start date was October 1, 2006. RA says this is a file concerned with rallying. This is obvious from context, but storing all your computer files with a strict naming convention can bring other benefits. CO means COmpetitor ... MA marshal, OF official etc. I use the next two characters to indicate the broad contents of the file; PR is short for PRess cutting, or it could be PHoto, REsults and so on. After that I add free-form narrative to fully qualify the file. In my example I have a PRess cutting from Motorsport News on October 5th. Note that I use an underscore to separate the parts, since spaces in a file name may present problems with some software packages.

In my final solution, I load a web page which allows me to select a driver or year, and then navigate to a particular event. The event page shows the database statistics, a list of appropriate files from the resources directory, plus clickable thumbnails images for the photos and press cuttings.

I've simplified this briefing because of editorial constraints, but there are links to a more detailed version and the products mentioned at http://regular.ity.me.uk.