Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

No PK or FK's in Warehouse Expand / Collapse
Author
Message
Posted Tuesday, September 18, 2012 4:07 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Sunday, October 20, 2013 3:13 PM
Points: 20, Visits: 79
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
Posted Tuesday, September 18, 2012 4:24 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Wednesday, August 27, 2014 2:46 AM
Points: 999, Visits: 13,480
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
Posted Tuesday, September 18, 2012 4:32 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Yesterday @ 7:09 AM
Points: 878, Visits: 2,395
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
Posted Tuesday, September 18, 2012 5:44 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 7:03 AM
Points: 15,738, Visits: 28,146
Animal Magic (9/18/2012)
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.


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 »

Add to briefcase

Permissions Expand / Collapse