[Roger Binns]
> I'd recommend you write code in your application first that knows how to
> calculate the values you want. That way you can ensure the calculations
> are correct, you have something for test harnesses that produces "good"
> values and you have something to port to your final solution.
>
> I'd probably stop there. Remember that your application code and the
> SQLite library are running in the same process. It is almost certain that
> it is (better/more convenient/easier to develop and use) for this code to
> be app code than within SQLite.
OK. But then I wont have an SQL interface for accessing interpolated
data. It's acceptable. An SQL interface is mostly a "nice to have",
so I could do some quick queries in SQL instead of having to write C
code for it.
> If someone will be doing queries expecting to match a row with second
> granularity then your SQLite side solutions are virtual tables and
> functions. The former is well documented. For the latter you can make a
> function like "reading" which behind the scenes calls your app code which
> prepares a statement, finds neighbouring readings and returns the
> interpolated result - eg `select reading("2012-01-01T012345")`
So, if I go for that approach, you'd recommend that I add functions,
such as "reading", and if I want a mean temperature, I should add a
function "mean" and not try to change what AVG will do?
Thanks,
--
Steinar
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
