If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > General > Database Concepts & Design > Table Design - Foreign Keys/Primary Keys

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 12-17-07, 10:41
Hawnted Hawnted is offline
Registered User
 
Join Date: Dec 2007
Posts: 4
Table Design - Foreign Keys/Primary Keys

I am designing a DB at work in PostgreSQL. It has a main facility table with an autogenerated primary key "id". I have a bunch of tables that spawn off this with more specific info about each facility. These tables all have a foreign key constraint that references facility. Is this the correct way to normalize the DB? Should each table have a PK AND a FK? Thanks
Reply With Quote
  #2 (permalink)  
Old 12-17-07, 11:09
r937 r937 is offline
SQL Consultant
 
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,524
is this correctly normalized? that depends on why you feel the "bunch of tables" had to be spawned off

should each spawned table (i.e. not including the main facility table) have both a primary key and a foreign key? yes!!
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
  #3 (permalink)  
Old 12-17-07, 11:27
Hawnted Hawnted is offline
Registered User
 
Join Date: Dec 2007
Posts: 4
Ok well there is a main facility table with the name address zip etc. Then there are more specific tables like network, server, APplication, etc. Each table that is not the facility table has a foreign key referencing an autogenerated number for each facility. But there is nothing else in each table that is unique. Is it OK that all I have is a FK in each table that is not the facility table?
Reply With Quote
  #4 (permalink)  
Old 12-17-07, 11:37
r937 r937 is offline
SQL Consultant
 
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,524
there is nothing else in those tables? okay, ditch them all

add a "type" column to your main table and you're done

__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
  #5 (permalink)  
Old 12-17-07, 11:39
Hawnted Hawnted is offline
Registered User
 
Join Date: Dec 2007
Posts: 4
no there is other stuff in the tables, just nothing else unique. The reason I separated the tables is because I grouped like information together.
Reply With Quote
  #6 (permalink)  
Old 12-17-07, 11:41
r937 r937 is offline
SQL Consultant
 
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,524
there is other stuff in those tables? okay, don't ditch them

make sure each of them has both a PK and an FK
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
  #7 (permalink)  
Old 12-17-07, 11:43
Hawnted Hawnted is offline
Registered User
 
Join Date: Dec 2007
Posts: 4
So can the PK be the same as the FK? Because if not then there is nothing else UNIQUE That can be the PK.
Reply With Quote
  #8 (permalink)  
Old 12-17-07, 11:44
r937 r937 is offline
SQL Consultant
 
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,524
yes it can
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
  #9 (permalink)  
Old 12-17-07, 14:52
wdoliver wdoliver is offline
Registered User
 
Join Date: Feb 2007
Posts: 3
Normally you completely normalize a database and then make adjustments for performance. Here are some simple guidelines for normalizing the database from the information provided.

Main Table(s): Facilities - Unique Key - only required columns (Must contain a value ALL of the time) should be in table.

There can be several Main Tables (I am using this term loosely) each based upon a specific area, entity, etc.. regardless the above rule applies.

If there is a many-to-many relationship then create a cross-reference table. (Contains primary keys of related records from both tables)

If there are optional columns associated with a table make a table for each. The only time a record will be added to the table is when there is optional information available. The table will contain a primary key (to ensure each record is unique) and the FK of the main record for which it is associated.

Hope this helps,
Reply With Quote
  #10 (permalink)  
Old 12-17-07, 14:58
r937 r937 is offline
SQL Consultant
 
Join Date: Apr 2002
Location: Toronto, Canada
Posts: 19,524
Quote:
Originally Posted by wdoliver
... The table will contain a primary key (to ensure each record is unique) and the FK of the main record for which it is associated.
you make it sound like those are separate columns -- they aren't
__________________
r937.com | rudy.ca
please visit Simply SQL and buy my book
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On