And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.
If you'd started from square one with a new database with no requirement to import legacy data it would be a fraction of the cost.
Why is legacy data so important? Just keep your brevet cards or better still maintain your own spreadsheet or use strava if you're that bothered. Personally I don't give a toss how many rides I did years ago. I can remember the ones I can remember, the rest obviously weren't that memorable.
That's only a fraction of the problem.
The bulk of the work related to results/awards is creating the schema for storing results data and the work needed to allow awards to be defined with minimal (ideally none) code changes (only changes in the awards DB) when new awards are devised, i.e. the awards themselves are not hard coded. This will all need to be done whether legacy data is imported or not if the new system is going to keep track of results and awards.
Once that's all done, mashing the legacy data into the new schmea format and importing it, and tweaking the system to produce the correct results is a relatively small chunk of work.
The only saving would be if the new system did not automate the tallying of awards (and/or results at all).
Oh I see, so it's about the system automatically recognising when someone has won an award.
That's not exactly rocket science.
I would model it as something like:
AwardDefinition
Name
Type
RideCollectionRequirement[]
RideCollectionRequirement
DateTimeScopeRequirement
RideTypeRequirement
CountRequired
DistanceRequirement
RideDefinition
Date
Type
Distance
So e.g. an award definition has a collection of ride requirements. Each ride requirement has a time span in which the matching rides must be completed, how many rides of that type are required, and what distance they are required to be. So a simple SR would be:
[
{DateTimeScope: WithinSameYear, RideTypeRequirement: BRM, CountRequired: 1, DistanceRequirement: 200},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BRM, CountRequired: 1, DistanceRequirement: 300},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BRM, CountRequired: 1, DistanceRequirement: 400},
{DateTimeScope: WithinSameYear, RideTypeRequirement: BRM, CountRequired: 1, DistanceRequirement: 600}
]
Fairly easy from there to write a matcher that detects new award won when a ride is entered.
There you go - job done, can I have a hundred grand?
And let's not forget all the complexity is purely so Ernest Higgins can check how many perms he did in 1986.
If you'd started from square one with a new database with no requirement to import legacy data it would be a fraction of the cost.
Not wishing to derail an otherwise interesting discussion, but once you have an event Entry system maintaining a Results system is quite trivial - Entries and Results are two sides of the same coin.
At its barest bones, an Entry is just a EventNo/MemNo pair of fields. A Result is just the same pair of fields with a third one added to show the status of that ride - Started, Finished, Validated whatever - you could even build simple Tracking into that 3-field schema.
Even when fleshed out with other stuff to deal with non-members, off-date rides (eg helper rides) etc etc, the Results table is a very simple thing. Assuming one row in the table = one ride, the Awards lists are simply queries on that table, the queries can sometimes be very complex but that's no big deal, they're all stored.
Yep, absolutely. (In my example above, 'RideDefinition' is analogous to 'Event', and 'Ride' would be synonymous with 'EventCompletion'.)