...
We get the need to reduce some of the overhead with respect to retaining prices historically - so the question is, is this price group in addition to what we already have, as a convenience, that might be ok, but it can't replace the more granular representation that we need for other use cases. We would need to show how this relates to the more detailed use cases. The max and min would be related to the trades executed on a specific exchange during a day, so perhaps a new structure that is exchange-specific, using the listing (as in Pete's example)?
We don't have a an obvious standard way of creating a summary of pricing statistics over some period, but could add that do have a PriceAnalytic class that could be augmented as a parallel structure to economic indicators. The Pete's use case is specifically for historical pricing, for representing historical performance of an instrument with respect to a specific source. It would be a summary of what happened in a given day of all the historical values - open, close, mid-price, official close, high, low, and possibly adjusted prices for all of the above. A trading day is perhaps the most granular thing, but a summary could be for any period of time.
...
Banks need to capture both the actual prices for trades, for example for an executed trade, and it's pricing source, etc. for valuation purposes. The issue is really the use case, so Pete's requirement is historical prices for performance analysis and reporting purposes, for a market data provider rather than for an institution, however.