Solved

Too many ID's or not really??

Posted on 2012-03-16
5
304 Views
Last Modified: 2012-03-17
I have a small database that I have normalized to about 3NF, but am finding about half of the tables have mainly foreign key ID's, and the actual data are stored in the other half of the tables. Part of the structure is hierarchical.

I am finding that I need to do JOINS for almost every type of query. Is it okay to have to do as many joins as necessary? Here is an example of the types of JOINS I am talking about:

SELECT table1.table1ID, table2.columnName1, table2.columnName2,
          table3.table3ID, table4.table4ID, table5.table5ID,
          table6.columnName1, table7.columnName1
FROM table1
INNER JOIN table2
    ON table1.columnName1ID = table2.columnName1ID
INNER JOIN table3
    ON table1.table3ID = table3.table3ID
INNER JOIN table4
    ON table3.table4ID = table4.table4ID
INNER JOIN table5
    ON table4.table5ID = table5.table5ID
INNER JOIN table6
    ON table5.table6ID = table6.table6ID
INNER JOIN table7
    ON table6.table7ID = table7.table7ID
INNER JOIN table8
    ON table7.table8ID = table8.table8ID
INNER JOIN table9
    ON table8.table9ID = table9.table9ID

I also find that I am finding it hard to test whether the data is correct since I have to follow the ID's to their actual data. I have made great success, but am also wondering whether there is an efficient way of dealing with all these ID's?
0
Comment
Question by:mitdaniels
  • 3
  • 2
5 Comments
 
LVL 42

Accepted Solution

by:
dqmq earned 250 total points
ID: 37732019
I think you mean that most of the tables have "surrogate key" id's.  And you've stumbled onto a rather controversial topic amongst database professionals.

I cannot speak with any certainty about your design, but in general I can tell you that there is nothing wrong with so many joins.  It's a normal side-effect (some say a disadvantage) of using surrogate keys.  

A common mistake is to use surrogate keys instead of natural keys.  That's wrong...surrogate keys should be declared in addition to natural keys.  That's important because natural keys carry important business meaning which you subject to risk if you do not declare them.

On the other hand, if you do declare natural keys in addition to the surrogate keys you have the option of propagating either one to the child tables and reducing the number of joins in many instances. It's a win-win for everybody.
0
 
LVL 42

Assisted Solution

by:dqmq
dqmq earned 250 total points
ID: 37732025
I forgot to mention one practice that may help you navigate the complexity of so many joins.  I'm referring to creating views to pre-join tables in commonly used combinations and return data from multiple tables in what looks and acts like a single table.

For example, you might have an "Employee" view that combines several different tables of related employee information.  Then, "Employee" encapsulates all the joins and can be used without any awareness of them.
0
 

Author Comment

by:mitdaniels
ID: 37732036
Thanks for the correction (surrogate keys).

Do you have an example?
0
 
LVL 42

Assisted Solution

by:dqmq
dqmq earned 250 total points
ID: 37732070
I can make one up.   Suppose we have these tables:

tblEmployee
---------------
EmpID (Surrogate Key)
EmpNumber 
EmpName

tblTask
--------------
TaskID (Surrogate Key)
TaskName

tblEmployeeTask
--------------------
ID (surrogate key) 
EmpID (FK)
TaskID (FK)

Then to return all tasks with assigned employee numbers:

Select TaskName, EmpNumber from  tblTask T
   inner join tblEmployeeTask ET on ET.TaskID = T.TaskID
   inner join tblEmployee E on E.EmpID = ET.EmpID  

note: two joins required

Open in new window


Now declare the same tables using natural keys:

tblEmployee
---------------
EmpNumber (Natural Key)
EmpName

tblTask
--------------
TaskName (Natural Key)

tblEmployeeTask
--------------------
EmpNumber (Natural Key, FK)
TaskName (Natural Key, FK)


Then to return all tasks with assigned employee numbers:

Select TaskName, EmpNumber from tblEmployeeTask

note: no joins required

Open in new window

0
 

Author Closing Comment

by:mitdaniels
ID: 37732124
Thanks so much, you've given me a few good pointers. I will see how to apply those to my database.
0

Featured Post

Complete VMware vSphere® ESX(i) & Hyper-V Backup

Capture your entire system, including the host, with patented disk imaging integrated with VMware VADP / Microsoft VSS and RCT. RTOs is as low as 15 seconds with Acronis Active Restore™. You can enjoy unlimited P2V/V2V migrations from any source (even from a different hypervisor)

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Why is this different from all of the other step by step guides?  Because I make a living as a DBA and not as a writer and I lived through this experience. Defining the name: When I talk to people they say different names on this subject stuff l…
Ever wondered why sometimes your SQL Server is slow or unresponsive with connections spiking up but by the time you go in, all is well? The following article will show you how to install and configure a SQL job that will send you email alerts includ…
Via a live example, show how to shrink a transaction log file down to a reasonable size.
Viewers will learn how to use the SELECT statement in SQL and will be exposed to the many uses the SELECT statement has.

803 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question