'Not using SQL directly' means you create a series data access interface
like an ISeries interface that browse in a cursor-style through your series
data, then implement it as a concrete class like DatabaseSeries that does
the SQL job for you.

Talking about scaling issues means that you could do some kind of data
manipulation best on processing by itself instead of executing SQL
statements (example: an data analysis study that take a series and output 3
new series with heterogeneous values, based on first data series, you can
calculate the resulting 3 series fetching data one time when you iterate
through you ISeries interface; executing 3 SQL statements will perform 3
read cycles, you can perform fast and also stop wasting CPU resources).

[]'s

-----Original Message-----
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Rick Ratchford
Sent: sexta-feira, 10 de julho de 2009 23:10
To: 'General Discussion of SQLite Database'
Subject: Re: [sqlite] Is it Possible in SQL...

#>I was trying to figuring out if you are doing something of 
#>graph data analysis, I do it almost everyday in our Stock 
#>Trader applications...
#>I never did this way (direct SQL), cause our graph series 
#>data sources are implement throught a common interface, that 
#>could be a SQL query, a stream, a XML, whatever.
#>
#>Just a tip: implementing specific and well designed 
#>interfaces for series data manipulation should be the right 
#>way for you, avoid scaling issues cause of possible SQL 
#>limitations in the ways those series can/should be 
#>manipulated in some cases.

This specific application requires very little user input. The user selects
a market (stock/futures) from a list of available data files and that is it.
The program then performs all kinds of different things on the dataset
selected and for the most part presents its results in the form of values.
There is one procedure, however, that will produce a 'graph' if the user
clicks on a button. That's pretty much it. 

When you said you never use 'direct SQL', are you saying that you never use
SQL that is hard coded in your program?

If so, perhaps in the case of my application requiring virtually no
interaction that it is acceptable for some of the internal procedures?

What are "scaling issues"?

Thanks. :-)
Rick







_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to