The problem with a "Prices" table is that in fact the things in it are largely uncorrelated
An index on Product and Time would sort that out for you. That's an important thing, records in a database aren't "consecutive" because they're not ordered except within the context of an index. You can have as many indexes as you like so "consectutive" becomes a concept you can have complete control over.

If you want to get data near to the person who wants it, use local databases replicated from a central source. In a situation like yours where the data is read only you'd use a simple publisher-subscriber model which is actually very easy to set up. And you could presumably set the refresh interval to a day at a time so the network traffic would be absolutely minimal. And your "Unit of Work" concern is neatly addressed in a replicated enviroment because the system will simply use a three phase commit where apropriate.

About the only good argument I've ever come across for splitting data across files and a DB was where a company needed razor fast writes into the system becuase multiple clients would all flush their data in at around the same time of day. Writes were actually made into a text file (which is muich quicker than a DB insert), effectively allowing deferal of the DB insert to a quieter time. For finding and reading data, as you seem to be, then having that data in a DB rather than a file is going to be orders of magnitude quicker - particularly for the "finding" part.