Graph Data Storage Preference
In general, what is everyone's preference for data storage?
For example,
1. I could read data files of multiple formats into a Database and use query operations to filter my data prior to loading into my graphing control...
2. I could use an internal dynamic array or linked list to store the data and implement custom query functions.
- probably less overhead than database?
3. I could load directly from the data file into the graph control.
My goal is to allow multiple channels to be selected and graphed from different CSV or other data files such that visual comparisons can be done fairly easily. The user would also be able to adjust the horizontal offset (time in this case) to line up "output current" between recording 1 and recording 2, for example.
Thanks Much,
Eric
[844 byte] By [
ezimmerman] at [2007-11-20 6:20:42]
# 1 Re: Graph Data Storage Preference
I don't think you should worry too much about overhead from a database. If you are using coordinates for graphing, a database will work just fine, so would a CSV file.
What do you mean by internal dynamic array? They are big words combined but I have never heard of that terminology before. Arrays are great for storing data and should be dynamic for user changes. But what do you mean internal?
# 2 Re: Graph Data Storage Preference
To me this hinges on performance questions.
Reading from a CSV, XML or similar data sources involves parsing. The parser will toss out values as it discovers them, and as such governs the speed of data acquisition.
If SQL Query gives you all of the query features you desire, then by all means, load the data into SQL for query, but there again the data comes out of the database only so fast.
Ultimately, the control that displays the data must paint. If you're developing in a non-event driven fashion (like DOS), once you show the data, you're done.
In Windows, X-Windows, MAC or similar GUI, you have to be prepared to paint the data on demand. This means containers, probably a vector, of what is selected.
That container CAN take the form of a bitmap. You can form the bitmap representation of the graph in a thread, taking whatever time you like from database query, CSV loading, etc. - then hand the finished bitmap over to GUI and tell it to refresh. Any time another paint message comes by, the GUI is just blitting the resulting bitmap image.
This approach makes sense if the data isn't changing in realtime, and isn't editable.
You can 'reform' a new bitmap each time the user selects new data, repeating the process, building up multiple streams of data as required.
Obvious optimizations include painting on the existing bitmap if a new stream is added, creating a new bitmap only if one of the existing streams of data were removed.
If performance is important, especially at the stage were data has been loaded and the user is experimenting with selecting various data sets, it will be faster if the data is loaded into containers (vector is probably a good choice if the data is a stream - no insertions/deletions of live content), and selection is made among that data in RAM.
Some additional issues come into play if you 'zoom' the data. Not so much in amplitude (that's just a scaling issue), but in extent (units of time, I suspect in your case). You can end up attempting to show more data than screen resolution allows, meaning that your display methods shift from a simple line graph (like a waveform) into something like an averaged swatch over the region. You couldn't expect to see meaningful info if you attempted to show, say, 5,000 data samples on the average display. This means you'd have to process the data into something meaningful for such cases.
That definitely means you'd want the data in vectors (or similar containers).
JVene at 2007-11-9 12:19:59 >
