Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries, Event 9 IIS log failed to write entry, wwwxxx jeffs, Catastrophic failure Unexpected method call sequence. 0x8000ffff (-2147418113)., ksh lock a file, [unixODBC][Driver Manager]Driver's SQLAllocHandle on SQL_HANDLE_DBC failed, sed: -e expression #1, char 1: unterminated address regex, procmail + change subject, w2ksp4.exe download, /proc/kallsyms format



#1: Data import - foreign key question

Posted on 2005-03-21 11:00:51 by teddysnips

This is a rather abstract question about data design, but I ask it here
because a) the database is SQL Server, and b) you're such a learned

Let's assume the classic relation of Customers and Orders, where an
Order may reference a single Customer. If I was designing such a
relation from scratch, I would create the Customer table with an
Identity column and call it CustomerID. The Order table would contain
a column called CustomerID, a foreign key to the Customer table.

So far, so unexceptional. However, in my current project I have to
work with legacy data that comes from a number of old Access systems
where the data was not normalised. I wish to normalise it.

The main table in this new system contains reports on parts. Each
report may reference a single part. However, the old data which I have
to import allowed the user to type in the part number. This has led to
dirty data (for example, '40-7889-9098' appears, as does '40-7889-
9098') so I will clean this data up. In the application, the part
number will be selected from a drop down list, though the administrator
will have access to a builder to add, amend or delete part numbers.

So, my report table needs to store a reference to a part. When I
import the data into my SQL Report table, I will initially bring across
the part number. I will then populate the Part Numbers table with all
discrete, distinct part numbers from the Report table. My question is
should I then create a PartNumberID column in both tables, and "back
populate" the Report table with the PartNumberID which corresponds with
the matching PartNumber - e.g.

R.fldPartNumberID = PN.fldPartNumberID
tblReports R
INNER JOIN tblPartNumbers RN
ON R.fldPartNumber = RN.fldPartNumber

I could then drop the fldPartNumber from the tblReports table.

My question is - should I bother? Or can I just leave the actual
PartNumber in the Reports table, and leave the tblPartNumbers table
with a single column which is both Primary key and Foreign key?

Sorry if this is poorly expressed - I had a tough weekend!

The reading group's reading group:

Report this message