I was the tech guy again for the horse show at the Ste. Gen County fair. Not a bad gig, but I am a terrible MS Access 97 designer, so the application is pretty bad, and generally wrong.
Actually, I can’t blame Access 97, I just did very poor requirements gathering and data analysis. Generally, you have riders, horses, and classes (a set of horses and riders doing something specific, competing against each other).
What I did wrong was assume that each rider has one number, and each number has one rider (one and only one is the phrase, in CS and math circles). It’s pinned to their backs, for crying out loud! I made rider-number a unique key on the Rider table.
Well, either things changed, or I just didn’t understand things. Now, the number is associated with the horse. Oftentimes, if two people are using the same horse, but in different classes, then they will sign up with the same number. Apparently, that’s how the big shows do it.
My workload now is typically 100% for the first hour and a half or so, as I try to slam in as many entries of horse/rider/class as possible, focusing on the earlier classes. After that initial rush, things trickle down to 20% or so, while I add in late entries and print off class lists.
I have an actual Access form for adding rows to the RiderHorseClass join table. That form doesn’t refresh its entry fields, so every change to Horse and Rider tables means I have to reopen the RiderHorseClass form and go to a new record. Because I have key-constraints in there, I also can’t just enter data without them being in the source tables.
Anyway, it’s a classic case of over engineering, Pat-style. I could almost denormalize the RiderHorseClass table and just allow free-form entry, if Access would be happy with that. I do want to avoid having to type Rider and Horse names in their entierty…
Problem is, I’ve been using the DB for 10 shows now, and I am too lazy to change. What do I do?
Anyway, one perk was this:
