On Fri, Sep 5, 2008 at 11:31 PM, jonwood <[EMAIL PROTECTED]> wrote: > I have a table where the primary key consists of two columns. I'm doing this > because these two columns combined must be unique, while each column is not > unique on its own. > > Because of the increased complexity of a dual-column primary key for some > operations, I'd like to use ROWID. But the documentation states the ROWID > can change at any time so I'm not sure what I can do safely.
Instead of doing this: CREATE TABLE t ( a TEXT NOT NULL, b INTEGER NOT NULL, PRIMARY KEY (a, b) ); Do this: 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. -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
