I am creating a program (mostly just for fun) that displays live prices for horse racing markets and the prices that several models predict they should be. I am very interested in the optimal way to structure this kind of data.

I need a Dictionary<int, (something)> to store <raceId, data> where the key (raceId) is a number I generate (to get rid of old races from the dictionary when the race is over). The vales (data) consists of the actual prices for each selection in the race and the prices of 3 separate models that correspond to each selection.

The dictionary will contain 20-60 races depending on the time.

Here is an example of the data for each race:

ActualPrice    ModelAPrice    ModelBPrice    ModelCPrice
3.25           3.26           3.29           3.20
5.60           5.63           5.55           5.57

The number of rows is usually around 40. Some of the models don't offer prices for some of the rows, but for each actual price there is at least 1 model price.

Additionally, for each race data I store strings for the RaceCourse, StartTime, Location, etc. I also store marketIds in the form of ints, these correspond to several rows at a time (these are used to place the actual bets), there are about 6 marketIds per race.

I was using a class to store all the data in called RaceData that is made up of fields for strings (i.e. RaceCourse, Location), ints (i.e. WinMarketId, PlaceMarketId) and doubles (i.e. HorseA_ActualPrice, HorseA_ModelAPrice, etc). So my dictionary is made up of <RaceId, RaceData>.

But I was wondering if instead it would be better to store the data over 3 Dictionaries.

Dictionary<int, Dictionary<string, string>> 
<RaceId, <StringName, StringValue>> 
Example of usage: Use RaceId=102313 and StringName="RaceCourse" to get Value="Flemington"

Dictionary<int, Dictionary<string, int>>
<RaceId, <MarketName, MarketId>>
Example of usage: Use RaceId=131231 and MarketName="WinMarket" to get MarketId=1321313

Dictionary<int, Dictionary<string, double>[]>
An array of dictionaries (one for each column of the data).
<RaceId, <RowName, Price>>
Example of usage: Use RaceId=12313 and RowName="HorseAWinPrice" to get Price=3.25

I'm not really sure if an array of dictionaries is needed for the last one, as I could just change the keys to have the column at the front, i.e. "ModelA_HorseBWinPrice" or "Actual_HorseBWinPrice". Which one is better?

Speed is a major concern when I have ~60 races and ~200 primatives for each. I have to perform several basic calculations using the values in each row for all of the races. I also need to display the racename/time in a listbox, and for the selected item in the listbox, display all of the prices on the form (in several list boxes). It is worth noting that each listbox corresponds to a marketId.

Which is a better solution or can you suggest a better one that I have not put forward?

2 Answers 2


Rather than using dictionaries I like the approach of using collections of classes for the different types. That would make the data more self-defining as well as allowing the use of LINQ to Objects to help aggregate and sort data. It will also make it more straightforward to bind to the list boxes.

  • I will opt to use Dictionary<int, RaceData>. I like your idea of using the lists inside for bindings and I will implement this. Thanks.
    – janderson
    Dec 29, 2013 at 11:05

But I was wondering if instead it would be better to store the data over 3 Dictionaries.

Short answer: no, that is not better - it is worse and will lead you directly into a maintenance hell. Don't replace well names, well structured data by anonymous data which is distributed over different containers though it obviously belongs together.

Speed is a major concern when I have ~60 races and ~200 primatives for each.

I don't know your actual calculations, but I guess you won't notice a big performance difference between those two alternatives. So choose the cleaner one (which is clearly the first).


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.