On 22 Jun 2013, at 10:50pm, Ryan Johnson <ryan.john...@cs.utoronto.ca> wrote:
> I considered that as well, but it's not clear how much benefit you get over > the autoincrement scheme: the PK-index is there either way, so that's not a > slowdown. The split table approach also makes query-writing and indexing > more complex, so at a minimum you'd probably want to make a view that runs a > UNION ALL on the two tables. If this really is a case of filling in missing information only in the 'new' rows, then there’s no need to search for lines with a NULL value in at all. Just keep track of which rows you’ve updated so far: CREATE TABLE updateprogress (tableName TEXT, lastUpdatedRowId INTEGER) When you have the time to update a table, do UPDATE myTable SET C1 = [calculation] WHERE rowid > [lastupdatedrowid] then update the updateprogress table. Since there is no searching needed, there’s no need for scanning the table, and no need for any indexes. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
