3000 inserts is really not much.
JChrisCompton wrote:1. I don't want the guid to be the clustered index because there will be inserts.
There were 3,000 inserts the first month, and I'm expanding from one category to four. No way to know the distribution of inserts (except 1st shift / business days) and I don't know the frequency of the other categories.
Fill factor == 100, not sure I can get it changed.
The best identifier is a proper name, see Eddys response I agree fully with him. And so does ISO 11179.
JChrisCompton wrote:2. I have the identity starting at -1 and decreasing by 1 to make it obvious that it isn't the pk.
Don't know how much this will help, but I do what I can.
I believe you're mixing up indexes with keys.
JChrisCompton wrote:3. I don't like the names ix_need_a_good_name_here, need_a_good_name_here_ix, need_a_good_name_here_id, because if I saw them I would assume that was the primary key. Suggestions?
The purpose of an index is to speed up the searching of a table, an index does not need to be unique.
The purpose of a key is to ensure the integrity of the database. A key needs an index for the function, but not the other way around.
If you create a clustered table, you should not use a guid as the key as you really should avoid random inserts on them. so either you use the identity column as the primary key and simply put a unique key on the guid column, or you use a nonclustered table.