Quote:
Originally Posted by MJC922
Thanks much for the info, I'm always grateful to have people like you and CJ who communicate these things. I'm supposedly now on an email list for notifications of the sort, this after missing the first three months of charts from that fairmount to fanduel debacle.
'Outer' course bit me a couple of years back too. For way too long of a time I was caught calculating these as dirt races until a customer was kind enough to report the races had been on turf. Big mistake. Yes I know I should've been a lot more in touch than I was but really do we need an outer anything? Unless there are three dirt courses or three turf courses then no, not IMO. Two courses anywhere just tag one as the inner and let the other be the main. Oh well, chalk it up to the stuff that happens over the years.
|
I have been developing off the RDS system for over 10 years now. It's a totally fine system and I'd guess the initial developers of it some 25+ years ago had both the domain knowledge and deep knowledge of how to build a robust relational database system.
The changes made to it since then all seem to be driven by those with specific domain knowledge about racing and absolutely no respect for how relational database systems should work. It is very frustrating since developing off of these systems is not cheap - both from the perspective of the cost of acquiring the data and building the racing knowledge to do so. You might be a black belt SQL slicer and dicer but if you have no racing knowledge, you are hopeless.
I would point out the FP/FAN debacle occurred right in the middle of the meet. The specific geographical location for the races themselves did not change of course. The O course type is one of the few structural errors the initial developers made - surface vs course type. There was no way to know in 1991 that there would be other "main track" type "surfaces" that were not dirt at that time. The decisions made since then have all been Frankenstein'd onto the structure itself and never actually corrected at the schema level structure. Again, very frustrating that something this important is not driven by someone at Equibase who has both deep knowledge of relational systems *and* racing knowledge. It's always seemed very blase to me to make changes like this without considering the broader ramifications for the relational systems that power all the horse racing data products in the US.