No PK or FK's in Warehouse

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 2008 » SQL Server 2008 - General » No PK or FK's in Warehouse

No PK or FK's in Warehouse

Rate Topic

Display Mode

Topic Options

Author

Message

waqqas.zia

Posted Tuesday, September 18, 2012 4:07 AM

Grasshopper

Group: General Forum Members
Last Login: Thursday, April 11, 2013 9:49 AM
Points: 19, Visits: 75

Good Morning, Afternoon and Evening (Depending on where in the world you are)

This is not a query just something which I'd like to know the pro's and cons for.

I have inherited a datawarehouse and was using the code here: http://www.sqlservercentral.com/scripts/Primary+Key+(PK)/93288/

to find the Primary Keys, but it appears that there are none.

Within Each table there is always a column called "Locator", eg. Job Tables has Job_locator, stock table has stock_locator. These "Locators" are used to link the a job with its relevant stock data, hence are the keys within the table.

What are the benefits of not stating PK and FK, and using this locator technique?

Surely there must be a method to the madness??

Post #1360658

Animal Magic

Posted Tuesday, September 18, 2012 4:24 AM

SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 9:08 AM
Points: 983, Visits: 13,350

All that PK and FK will do for you is introduce data integrity. Depending on the source of the warehouse data the creator may already know that the data is consistent and therefore doesn't need to add any extra checks. or maybe they are not too worried if a header record doesn't exist and their are orphaned child records.

Assuming the tables are indexed i would guess that the no PK/FK is by design, but its a rather large assumption.

Post #1360667

Jason-299789

Posted Tuesday, September 18, 2012 4:32 AM

SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 1:30 AM
Points: 803, Visits: 2,124

When you say data warehouse do you mean a Kimbal Star/snowflake Schema?

Depending on the original developer you may find PK's but no FK's, although its not unheard of to have no PK's either (and rather shody IMHO).

In the case of missing PK's I suspect there will be a clustered/unique indexes on either the natural/business key columns and/or the surrogate key column.

In regards to FK's it depends on the type of DW load process, if its a full refresh (Ie Truncate and Reload every table) then you are unlikely to find FK's on the tables due to the extra effort needed to drop all the FK's prior to the clear out, and re initiate them after the load, as well as the headache associated with issues arising when RI is blown.

Ifs its an Incremental load then FK's are likely to be in place as theres no need to drop and recreate them as part of the ETL process, but they may be set up with NoCheck.

_________________________________________________________________________
SSC Guide to Posting and Best Practices

Post #1360670

Grant Fritchey

Posted Tuesday, September 18, 2012 5:44 AM

SSChampion

Group: General Forum Members
Last Login: Today @ 7:59 AM
Points: 13,381, Visits: 25,166

Animal Magic (9/18/2012)

Not at all true. Constraints are used by the optimizer to make choices in how it runs the queries that you submit to it. Those constraints can absolutely affect performance in a positive manner. I have a small example on my blog.

----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software

Post #1360707

« Prev Topic | Next Topic »

Permissions