[Webinar] Streamline your web hosting managementRegister Today

x
?
Solved

Too many ID's or not really??

Posted on 2012-03-16
5
Medium Priority
?
354 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 1000 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 1000 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 1000 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

The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

Question has a verified solution.

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

What we learned in Webroot's webinar on multi-vector protection.
In this article, we will show how to detach and attach a database and then show how to repair a corrupt database and attach it, If it has some errors. We will show how to detach and attach using SSMS or using T-SQL sentences.
In this video, Percona Director of Solution Engineering Jon Tobin discusses the function and features of Percona Server for MongoDB. How Percona can help Percona can help you determine if Percona Server for MongoDB is the right solution for …
With just a little bit of  SQL and VBA, many doors open to cool things like synchronize a list box to display data relevant to other information on a form.  If you have never written code or looked at an SQL statement before, no problem! ...  give i…

612 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