[Simon Slavin] > On 13 Feb 2012, at 7:51pm, Steinar Midtskogen wrote: > >> One should think that the ability to calculate a moving average would >> be a pretty common request. But people do it in their application >> code instead? > > Actually, my expectation is the other way. I'm continually surprised by > posts on this list that people expect to be able to use SQLite with no > external programming at all. I often see complicated compound JOIN and > sub-SELECT SQL commands here which can be replaced by four lines in any > programming language, yielding faster simpler code which would be easier to > document and debug.
Well, yes, to do things in C or similar when SQL becomes too unwieldy is precisely what I want, but the question is rather whether it's feasible to do it within SQLite's framework for custom functions and virtual tables. This is the first time I do something with SQLite, so my naive approach is that anything would be neater to have as custom functions or virtual tables before doing it completely ad hoc in C. Not just for the sake of using one of SQLite's key features, but to keep things more reusable and to keep the core application as simple as possible. On the other side, I realise that if the API is to grant every wish any programmer might have, it will break one of SQLite's other key features: simplicity. I think in this order: 1. Feasible using SQL? 2. Feasible using custom functions? 3. Feasible using virtual tables? 4. Ad hoc application code. Perhaps number 4 will get me faster to my goal right now, but I'd like to think that trying the approaches higher up first can give me something back in the longer run. -- Steinar _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
