Racing Database Redesign - Part 1 - The Objectives

Although this is a new project, I already have much of the database design in place, together with a lot of the automation. However, it was created sometime ago and I’ve since altered my requirements inspired by additional strategies I have developed in the meantime. In addition, much of the automation relied on calls to the old Betfair API which is no longer operational. It was the decommissioning of that API which has ultimately led to the desire to completely revamp things.

With this in mind, I want to take the opportunity to tweak the database design somewhat so that it fits in more with the way I’m thinking now. I’ve still to decide how to automate much of the functionality - do I throw myself into learning the new API or do I scrape the Timeform site (among others). There’s pros and cons for both methods which I may discuss in a later article.  For the moment, I simply want to document the objectives together with any optional extras as well as identify any potential issues.

Objectives - In no particular order:

1. The principal aim is to record the horse racing data freely available from Betfair at into a more suitable format to allow ease of data input and analysis with a view to generating new strategies and automatically suggesting suitable strategies to use on a race by race basis.

2. Automate the data gathering process so that data entry is kept to a minimum if not eliminated completely.

3. Allow for expansion of the database to include data not provided in the aforementioned Betfair data files. This might include information about jockeys and trainers as well as the horses themselves. This need only be implemented if a suitable source of historical data can be found that would allow its automated importation. Manually inputting such data for thousands of races going back to 2009 is clearly impractical.

4. It should be possible to analyse the data to investigate long term suitability of any number of strategies both known and unknown. Existing strategies such as DOBbing, LTF, Back to Lay, Dutching and scalping all spring to mind.

5. Although trading in the place market is not a requirement, accommodation for the place market data from the Betfair website should be made. Specifically, whether a runner was placed or not in a particular race should be recorded.

6. A web based interface is required to reduce the amount of time needed to manually assess a race card. It should be capable of: displaying the runner graphs from the Betfair site on a race by race basis (similar to the existing graphing shown here); providing a summary of the runners in a race with a view to suggesting the best strategy to use for each race; providing a daily summary of all runners with a view to identifying possible long term swing trades.

7. The database and associated interface is not intended to be a betting bot, automated or otherwise. However, the design should not prevent that possibility in the future.

8. The database and associated interface should be cross-platform and accessible from any device available. Indeed, the implementation should not dismiss the possibility of accessing the system remotely over the Internet or exclude the possibility of making the system available to the general public as an Internet based service.

9. The system should automatically download and import all results on a daily basis without user interaction though there should still be the facility to have that process manually initiated.

Those are the main areas I want the system to be capable of. No doubt others may well spring to mind but I imagine they will be relatively minor.

Before I go on to discussing the design of the database itself, I’ll be mulling over how I intend to implement the system to meet the aforementioned objectives. I shall outline those thoughts in the next instalment so stay tuned for that.

No comments: