There are a few reasons for the two-database method would be useful versus a single database connection, depending on the volume of data in the pot.
1> Having a single hourly database will keep the database size minimal. ~8000 entries holding just temperature data, it'll be small so I can't see a write taking longer than 10 seconds. 2> Backing up a large database that could potentially take longer than 10 seconds to backup, you might end up in a race condition. If an insert at the next 10 second mark causes the backup API to start over again, who's to say that 20 seconds down the road the backup will restart again? 3> Depending on the kind of historical look up needed, picking a day/time range would be as easy as attaching the required databases, in code, (re)generating a temporary view to join the look ups would be simplistic. The data could be considered "read only" and be safely read from a network share on another machine as to not disrupt the Pi. Depending on the structure of the code, if a two-database setup is daunting to implement, the other option available, I suppose, is to do a bulk insert from the memory database to the SD database in one transaction once an hour, and when the bulk insert is completed, delete the in-memory contents and continue on. You should still be looking at a decent output times (Just a few thousand small rows which probably amounts to only a small-few hundred pages) so I think even writing to an old school 720k floppy diskette should be quick enough. Depending on the language, you could just entirely skip the in-memory database and just remember the data recorded from the Pi by dumping it into an array, then hourly dump the data into the database. On Wed, Feb 12, 2014 at 4:03 AM, RSmith <rsm...@rsweb.co.za> wrote: > > Actually, the Backup-API is clever like that, it will automatically void > and re-start the backup when data changes happen. Of course this might be > equally detrimental if you update more frequently than the backup takes to > complete, in which case the system would be in permanent backup and any > gains voided. > > Maybe stop the updater till the backup is finished... it should however > not take 10s, so it _should_ be safe, but I would put it in the > precautionary wait state just to be safe. > > > _______________________________________________ > 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
