design choice: multi-threaded / asynchronous wxpython client?

[David]

>  Tempting thought, but one of the problems with this kind of horse
>  racing tote data is that a lot of it is for combinations of runners
>  rather than single runners. Whilst there might be (say) 14 horses in a
>  race, there are 91 quinella price combinations (1-2 through 13-14,
>  i.e. the 2-subsets of range(1, 15)) and 364 trio price combinations.
>  It is not really practical (I suspect) to have database tables with
>  columns for that many combinations?

If you normalise your tables correctly, these will be represented as
one-to many or many-to-many relationships in your database. Like the
other poster I don't know the first thing about horses, and I may be
misunderstanding something, but here is one (basic) normalised db
schema:

tables & descriptions:

- horse - holds info about each horse
- race - one record per race. Has times, etc
- race_hourse - holds records linking horses and races together.

You can derive all possible horse combinations from the above info.
You don't need to store it in the db unless you need to link something
else to it (eg: betting data). In which case:

- combination - represents one combination of horses.
- combination_horse - links a combinaition to 1 horse. 1 of these per
horse per combination.
- bet - Represents a bet. Has foreign relationship with combination
(and other tables, eg: better, race)

With a structure like the above you don't need hudreds of database columns :-)

David.