This is the only reason I can think of for the redundancy and was actually thinking of it earlier.
Consider the basic "select count(*) from ...;" If you've got a lot of fields, or if they're large fields, then the fanout of your records means you may have to get a whole bunch of pages to find how many records you have. An index on just the rowid is as compact as possible and would provide the fastest possible answer to the basic count query. Hmm, it would also provide quick checking of foreign keys if it's a parent table. Might also be useful in some joins as a quick way to see if there's a match etc. So yeah, there are some possible reasons for it. The "unique" bit is redundant, but if you want that extra index for one of the above mentioned reasons, then it means you can create it right there for 1 extra word. Of course without a comment in the create statement no one's gonna understand why you put it there, and everything will function just fine without it. -----Original Message----- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Keith Medcalf Sent: Friday, May 19, 2017 3:06 PM To: SQLite mailing list Subject: Re: [sqlite] auntondex with unique and integer primary key Perhaps there is a reason that you want a separate unique index. Maybe the table has 15000 columns and from time to time you just need to be able to scan the used RowIDs without incurring the penalty of wafting to and fro all over the disk. _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
