Re: Does it make sense to have 2 unique keys in one table?

In article <45uotk$kh7@newsbf02.news.aol.com> dmajor7@aol.com "Dmajor7" writes: Although I am no expert in this area, it seems to me : that you could gain some performance by not requiring key1 to be unique. : Key2 being unique is going to insure that key1 is unique anyway so why : waste time having the database check for something that is impossible. There is a marginal storage benefit in declaring a key as unique. If a key is unique, the rowid is stored as a fixed 6 bytes in in the 'header' information for the item. If the key is non-unique, the rowid is appended to the key definition as if it were a real column, and not stored in the 'header'; but to be treated as an ordinary index in the column, it has to be preceded by a 'length byte'. Net result: rowids in unique keys require 6 bytes, rowids in non-unique keys require 7 bytes. Then again the original example had a 4 column index as its 'spare' unique index, so what difference does one more byte per entry make. -- Jonathan Lewis