Hi Shawn,
Have you looked into ECO in the latest incarnations of Delphi? Its kindof the Bold but for .net. It is quite a smart Object Persistence Mapper, doing most of the work of talking to the database for you. The reason I mention it is your reference to some kind of caching system. Well, it already implements one so that data retrieval isn't duplicated where it isn't necessary. On receipt of data, you could create the objects and they would remain in memory until you find a convenient time to persist the new objects to the database by calling UpdateDatabase. Interfacing with ECO data is just like normal .net data binding, so its pretty easy, and it also can control your database structure for you, reducing greatly the development time. I've written a Mapper to allow use of the Firebird ADO.NET Provider, which should allow you to use the Embedded Firebird version, should you so wish. Hopefully that would provide an embedded solution, with a good data backend. Kind regards, Scott Price :) Shawn Jones wrote: > I'm developing an app that will collect and display real-time market data. > This data often times arrives is surges at which time maintaining minimum > cpu utilization is important therefore I'm concerned about Insert > performance. > > I'm thinking some type of caching scheme would be appropriate where the > quotes accumulate in the cache and would be periodically updated. > > I need to display the real-time quotes and display real-time charts with > history, therefore I need to be able to read the cached data and the > persisted data on chart refreshes. > > I'm guessing this is not that unique of a requirement and therefore don't > want to reinvent the wheel. This will be a single user app with no near > term plans for any type of client server architecture therefore an embedded > type solution would be preferred especially if higher performance (lower cpu > utilization) can be achieve with an embedded solution. > > I'm somewhat of a rookie with databases and would appreciate any thoughts > and suggestions on how to structure this or any specific database > suggestions. > > shawn > > _______________________________________________ > Delphi-DB mailing list > Delphi-DB@elists.org > http://www.elists.org/mailman/listinfo/delphi-db > > > _______________________________________________ Delphi-DB mailing list Delphi-DB@elists.org http://www.elists.org/mailman/listinfo/delphi-db
