May 13, 2007 at 9:33 pm
My DBA intentionally let some code in that dropped the PK from a table with no replacement... can anyone think of a good reason not to have a PK? Not even a surrogate key? Seems a bit insane to me but I thought I'd ask...
--Jeff Moden
Change is inevitable... Change for the better is not.
May 13, 2007 at 10:22 pm
Not sure if it fits with your scenario, but what about if that table only ever had one row of data
--------------------
Colt 45 - the original point and click interface
May 14, 2007 at 12:13 am
- maybe all he wants is a fast logging-kind of table.
(pumping it away to another server for querying/investigating and providing it with indexes overthere 
IMO even this kind of tables should have a unique key for every row
A regular table should have a PK (or unique key replacing it)
(just like Codd taught us)
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
May 14, 2007 at 12:29 am
Phil's reason is the only one I can think of. Such tables are not really "tables" per se but are represented as tables in SQL Server in the absence of anything else. I suppose you could have a setting=value sort of table with two columns rather than a wide table with a single row where each column contains a setting's value.
May 14, 2007 at 5:57 am
Thanks, guys. Yeah, the only thing I could think of was a minimal logging bulk insert staging table but he's not using it for that... it's a permanent cross-reference table being used to resolve multiple-to-multiple joins. I just can't imagine not having a primary key on those two columns.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 14, 2007 at 6:44 am
.. multiple-to-multiple ..
indeed, it's best to avoid duplicates, so at least a unique constraint may be advisable. If it should be a primary key ?? (are there going to be child tables related ?)
In most cases, many to many relationships contain extra info about the relationship itself (e.g. datecreated/dateexpired, resoncodes,... kind of stuff)
I'd certainly support it with the FK-indexes and provide a clustering index somehow because of maintenance issues with heaps.
Johan
Learn to play, play to learn !
Dont drive faster than your guardian angel can fly ...
but keeping both feet on the ground wont get you anywhere :w00t:
- How to post Performance Problems
- How to post data/code to get the best help[/url]
- How to prevent a sore throat after hours of presenting ppt
press F1 for solution, press shift+F1 for urgent solution 😀
Need a bit of Powershell? How about this
Who am I ? Sometimes this is me but most of the time this is me
May 14, 2007 at 7:02 am
Good reason: Brain fart?
I have a few tables without indexes, but those are for like where I am storing information about logins and I am more worried about inserts being fast. That table has one stored procedure that runs against it every morning to summarize which logins where used the previous day, store that information in another table (with indexes!) then delete the information.
May 14, 2007 at 7:36 am
I could see allowing duplicates in a table for some reason, but you'd still want a PK in case you ever needed to work with a row. Even in a logging or counting table you'd still want a PK, even if it were a surrogate.
May 14, 2007 at 9:36 pm
Yep... that's the position I was taking... just wanted to make sure there wasn't some exotic reason I was missing. Thanks for the feedback, folks.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2007 at 12:18 am
I think Anders gave the best answer!! The only other plausible reason is that he's trying to make you look better by intentionally doing bad things.
May 15, 2007 at 1:32 am
Heh... maybe that's it! I should thank him, huh?
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2007 at 6:37 am
Even that type of table should have PK, just not necessarily a clustered key.
The only two examples I have ever seen is temporary working tables for bulk import (where you do not want to drop rows or fail import before you can check and vailidate data), or a table with a single row.
Mark
May 15, 2007 at 7:13 am
In SQL Server 2005 it is possible to use the ROW_NUMBER function to sort data easily without a primary key. Not sure if this was your DBA's intention, but may be worth asking.
May 15, 2007 at 7:43 am
Not sure what you mean, Ronda. What kind of a sort are you talking about?
My real concern is over "entity integrity".... or, if you will, a table without a Primary Key is only a "heap" and many applications will fail (like Enterprise Manager) if you try to modify or delete a row that has been duplicated unless there is a tie breaker like a primary key column (clustered or not). And, Even if the table is not exposed to an external application, there are usually some performance gains to be had by having a primary key constraint and the accompanying index that results.
--Jeff Moden
Change is inevitable... Change for the better is not.
May 15, 2007 at 7:57 am
I'd be curious to see the DDL for the table and its associated object(s) ...
RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."
Viewing 15 posts - 1 through 15 (of 71 total)
You must be logged in to reply to this topic. Login to reply