-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 07/02/12 23:14, Steinar Midtskogen wrote:
> I'm not asking the list to solve these problems for me, but it would
> greatly help if anyone could point me to the right direction. Which
> approach would work?
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.
If you need other code to access the database and your application code
cannot be used then you can use one of the mechanisms you mentioned such
as virtual tables. However it has been my experience that faking data
integrity for other code tends to lead to bugs and other issues in that
code because they don't realise what is going on. (The initial programmer
might, but in 6 months someone else does maintenance.)
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")`
Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iEYEARECAAYFAk8yKgAACgkQmOOfHg372QQxBgCfd07QCC8/f2caqq4d0EZLHg67
d0UAoKcm/eVV/MsUdGk+XgHnXuDWXOLJ
=OGRj
-----END PGP SIGNATURE-----
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
