Great! Thanks, Chris
Rick
> -Original Message-
> From: Chris Terrebonne [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 15, 2005 8:04 AM
> To: CF-Talk
> Subject: RE: Database Normalization Question
>
>
> In a relationship model like this, you can track histo
Sounds good...thanks Kerry!
Rick
> -Original Message-
> From: Kerry [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 15, 2005 6:25 AM
> To: CF-Talk
> Subject: RE: Database Normalization Question
>
>
> just a small point, the 2 table system does allow for
April 14, 2005 3:49 PM
> To: CF-Talk
> Subject: RE: Database Normalization Question
>
>
> What happens you you have the same employee, but has been moved to a new
> position and you still need to keep the history?
>
> For example, last year I was a grunt. This year, I a
:[EMAIL PROTECTED]
Sent: 14 April 2005 20:53
To: CF-Talk
Subject: RE: Database Normalization Question
Well...if it was a one-to-one relationship always, and I had a two-table
db design, it would work, because I could simply update the employee's
profile and use a drop-down to reassign the pos
table, double-field primary key design...
Right?
Rick
> -Original Message-
> From: Dawson, Michael [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 3:49 PM
> To: CF-Talk
> Subject: RE: Database Normalization Question
>
>
> What happens you you have th
What happens you you have the same employee, but has been moved to a new
position and you still need to keep the history?
For example, last year I was a grunt. This year, I am a slave. How
would you track that?
-Original Message-
From: Rick Faircloth [mailto:[EMAIL PROTECTED]
Sent: Th
Stoner [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 2:56 PM
> To: CF-Talk
> Subject: Re: Database Normalization Question
>
>
> You don't actually need the Employee_Position_ID, just make the
> primary key
> out of both the Position_id and Employee_ID colum
ROTECTED]>
To: "CF-Talk"
Sent: Thursday, April 14, 2005 2:37 PM
Subject: RE: Database Normalization Question
> Thanks, Chris & Jochem...
>
> Yes, I believe I understand...I've just never run into a situation
> that forced the usage of the third table for me...su
Makes sense...thanks!
Rick
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 2:31 PM
> To: CF-Talk
> Subject: RE: Database Normalization Question
>
>
> Rick
>
> What you are referring to is a
tive?
Rick
> -Original Message-
> From: Jochem van Dieten [mailto:[EMAIL PROTECTED]
> Sent: Thursday, April 14, 2005 2:25 PM
> To: CF-Talk
> Subject: Re: Database Normalization Question
>
>
> Rick Faircloth wrote:
> >
> > Positions (Yes, I li
Rick
What you are referring to is a link table often used when you have a many to
many relationship, if you have a one to one relationship then there is no
need.
>
>
> It seems like the third table is used to tie the Positions table and
> Employees table together, but I don't see the benefit
Rick Faircloth wrote:
>
> Positions (Yes, I like plural table names :o)
>
>Position_ID (Primary Key)
>Position_Title
>Position_Description
>etc
>
> Employees
>
>Employee_ID (Primary Key)
>Position_ID (Relational Key)
>Employee_FirstName
>Employee_LastName
>et
The third table allows for a many to many relationship. So a person can
have more then one position in your example.
- Original Message -
From: "Rick Faircloth" <[EMAIL PROTECTED]>
To: "CF-Talk"
Sent: Thursday, April 14, 2005 2:08 PM
Subject: Database Normalization Question
> Greetin
13 matches
Mail list logo
