Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Table Creation: Referential Integrity

Status
Not open for further replies.

boanrb

Programmer
Mar 3, 2009
53
KE
Hi Friends,

I am trying to get my hands on SQLSERVER - am a newbie- and wanted some direction on how to properly setup my three tables:

Table1 : Employee Records

EmployeeID auto Identity,
First_name char,
Last_name char,
DateOfHire datetime (and many more fields)

Table2 : Unprocessed salary records (accepts raw data which is processed and stored in a history table)
(EmployeeID,PayItem) compined must be unique.

EmployeeID, (necessary on this one or I introduce a surrogate PK?)
StaffNumber char, (this takes different formats and can change)
PayItem char,
ReferenceID char,
amount float, (and some other fields)

Table3 : Processed data - Historical
(EmployeeID,PayItem,Period) compined must be unique.

EmployeeID, (necessary on this one or I introduce a surrogate PK?)
PayItem char,
Period char, (eg 2013-01, 2013-02 etc)
Amount float (and some other fields)

For the purposes of reference, would I need a separate primary key on Table2 & Table3?
Or can I use composite (EmployeeID,PayItem)?
If composite is 'expensive', (data will really grow), how do I structure Table3?

Table2 & Table3 will refer to Table1 for staff details but will no be refered to for anything.

My questions may not well structured but I hope someone understands what I need.

Kindly assist as I am new and just making some effort to establish good practices. (ORM is fully in mind.)

Thanks alot.

Benson



 
There is nothing wrong with composite keys. I use them all the time.

You will want to be careful about the key length (basically the amount of data that makes up the key). Obviously EmployeeId is an integer, but the other column is "PayItem char". What will the normal length of this value be? What values will this store? If this is a long-ish string, I would encourage you to create another table that stores:

PayItemId Int Identity,
PayItem char

You could then store the PayItemId in the tables instead of a long string.

If PayItem is a "code" that will not exceed 5 or 6 characters, then you won't need to worry about this.

-George
Microsoft SQL Server MVP
My Blogs
SQLCop
twitter
"The great things about standards is that there are so many to choose from." - Fortune Cookie Wisdom
 
Hi George,

Thanks for your reply. PayItem is 4 chars only.
Appreciated.
Benson
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top