June 25, 2002 at 12:41 pm
I have a table which has been designed with no Primary Key but just a clustered index spanning two columns . The reason given by the developer is that it needs no PK as it isn't the target of any foreign keys and as it wil hold 60 million rows when full this will give the optimum for quick updates and reasonably quick retrieval.
Hi,
I would like to partition the table horizontally by a date column, but would welcome any comments on this indexing strategy. It doesn't feel right to me.
June 25, 2002 at 4:20 pm
Im all in favor of primary keys, even if you have to contrive one.
Andy
June 25, 2002 at 5:42 pm
I agree. you should have some primary key. You can make it non-clustered (recommended).
Steve Jones
June 25, 2002 at 5:52 pm
ALthough a primary key is not absolutely needed it is best to have one as you need to ensure data entities as opposed to possible duplications. Although you may not have a field that is unique that can be used as a PK consider adding an IDENTITY column. The big reason is you need to work with a specific row you can have an issue if you have no way to uniquely ID two rows with the same data and thus overwrite more than one record.
"Don't roll your eyes at me. I will tape them in place." (Teacher on Boston Public)
June 25, 2002 at 11:30 pm
Hi thanks for the replies.
So adding a non clustered PK will not be detrimental to queries or updates? I wuld be in favour of this, together with the partition I mentioned.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply