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

Reply via email to