Scott Hess wrote: > > CREATE TABLE t ( > id INTEGER PRIMARY KEY, > a TEXT NOT NULL, > b INTEGER NOT NULL, > UNIQUE (a, b) > ); > > (a,b) will be just as unique as in the first case, but now you can use > id as a stable alias for rowid. There will be the same number of > btrees (one keyed by rowid/id for the table, one for the index on > a,b), and things should take the same amount of space (since id is an > alias for rowid, not a new column). > > As a bonus, if the implementation of SQLite changes, SQL itself won't, > so id will _still_ be a valid integer primary key, even if the > implementation detail of rowid changes. >
Many thanks for the speedy response. I need a little while to absorb this and consider all the ramifications. But my initial thought is that this solves the issues in an easy and stable way. Thanks again. -- View this message in context: http://www.nabble.com/Help-Using-RowID-tp19343483p19343677.html Sent from the SQLite mailing list archive at Nabble.com. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
