Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!
  • Students Click Here

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here


Table Creation: Referential Integrity

Table Creation: Referential Integrity

Table Creation: Referential Integrity

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.


RE: Table Creation: Referential Integrity

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.

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

RE: Table Creation: Referential Integrity

Hi George,

Thanks for your reply. PayItem is 4 chars only.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members!

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close