#>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
