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
3NF depends on "The Key, the whole key, and nothing but the ley... so
help me Codd"
I have found an excellent chapter in Martin Gruber's "Mastering SQL"
about the various stages of normalization... and they are just that,
stages!... a database is not usually thought of "Normalized" or
"Denorm
At 07:21 PM 04/15/2001 -0400, you wrote:
> > you're usually much better off with a fully normalized database.
> >
>
>Dave,
>
>when you say "fully" do you mean we should strive for third-normal form? Or
>should be be stretching to go further?
Did you mean third, or fifth normal form?
I alway
> > you're usually much better off with a fully normalized database.
>
> when you say "fully" do you mean we should strive for
> third-normal form? Or should be be stretching to go further?
>
> (reporting issues aside--I mean what should we shoot for
> unless we have a reason not to?)
Fourth a
> you're usually much better off with a fully normalized database.
>
Dave,
when you say "fully" do you mean we should strive for third-normal form? Or
should be be stretching to go further?
(reporting issues aside--I mean what should we shoot for unless we have a
reason not to?)
> Normalizing the database will reduce the size of the database
> and help ensure that the data is clean and consistent. But if
> you're concerned with performance, typically you would
> "de-normalize" the database.
I feel compelled to point out that denormalization doesn't always provide
bett
Normalizing the database will reduce the size of the database and help
ensure that the data is clean and consistent. But if you're concerned with
performance, typically you would "de-normalize" the database.
You might consider buying a book on modeling. Anything written by Ralph
Kimball is pretty
19 matches
Mail list logo
