Comments on: The Query Optimizer’s handling of Relationships for T-SQL Tuesday #003

By: Rob Farley

Rob Farley — Sun, 14 Feb 2010 05:51:39 +0000

@Joe – Thanks for that. I didn’t realise that, and it makes for some interesting thoughts. I do wish that SQL Server did it that way – perhaps at some point it might, or maybe that’s just a pipe dream.

@RobLobbe – Sorry, we’ll have to disagree on that one. I’ve seen too many situations where the Query Optimizer has been able to run a query so much better because a Foreign Key is in place. I’ve also seen too many situations where a database without FKs has referential integrity issues, and I would always want my Test and Production systems to be identical. Thanks for commenting though – it’s always good to hear other perspectives.

By: Rob Lobbe

Rob Lobbe — Sun, 14 Feb 2010 05:35:24 +0000

Foreign Keys are a DESIGN tool. And should be treated as such. As far as the Query Optimizer goes, it should NEVER be an issue in my production database. FK’s should be removed, as they only cause overhead to day-to-day processing.
It the feature of an application is to ‘display an error for every FK breach’ the vendor’s going to get an earful for a shoddy product. Likewise if the product is relying on a cascade delete, what else are they ‘guessing’ at – especial if I want audit’s and history retention.
In a development, or testing environment, sure put them in. They make sure the application doesn’t break the rules, but from an optimizer standpoint I’m not concerned with this overhead – the final product will be that much better, without them.

By: Joe Celko

Joe Celko — Sun, 14 Feb 2010 02:06:05 +0000

FYI

Sybase and other SQLs implement the PK-FK relationships as pointer chains that connect the FK to the single PK value in the entire schema. They think of the schema as a whole. You can see the advantages of this for CASCADE, JOIN and other operations.

SQL Server and other lesser SQLs implement each table separately as if they were files, so the PK value is repeated over and over in the FK columns. To get good join performance, you usually index FKs in such products.

SQLs that use hashing actually want longer keys because they hash with fewer collisions.

By: Jeremiah Peschka

Jeremiah Peschka — Tue, 09 Feb 2010 20:34:49 +0000

I’m guessing you’re referring to the difference between using a surrogate key and a superkey. I make that guess because if your PK is on a natural candidate key, it wouldn’t be a question.

As long as the unique index has all included columns for queries (effectively making it a second clustered index), I would say that it’s probably a better candidate for the FK than the artificial PK.

While we’re frequently told we should use surrogate PKs, isn’t it more important to balance logic and reason (referencing the natural candidate key) with convenience (referencing the surrogate key). A pure relational theorist, of course, would say to use the natural key. I’ve used with both and haven’t seen appreciable differences in application performance. These days the choice comes down to what my predecessor has done.