We were just talking about a situation much like this on another
newsgroup.  And it was pretty much decided the best way to go would be to
add the data as it comes in to an in-memory table, running any queries and
or filling any grids directly from it.  Then at a set interval or when idle
use a transaction to Post the data.  At the same time any data no longer
relevant to the user could be deleted from the memory table.

from Robert Meek dba Tangentals Design  CCopyright 2006
Proud to be a moderator of "The Delphi Lists" at elists.org

"When I examine myself and my methods of thought, I come to the conclusion
that the gift of Fantasy has meant more to me then my talent for absorbing
positive knowledge!"
                                                    Albert Einstein


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Shawn Jones
Sent: Thursday, August 03, 2006 3:53 PM
To: [email protected]
Subject: Database Design Suggestions

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
[email protected]
http://www.elists.org/mailman/listinfo/delphi-db

_______________________________________________
Delphi-DB mailing list
[email protected]
http://www.elists.org/mailman/listinfo/delphi-db

Reply via email to