I've noticed that being done, too. Multiple-field Primary Keys... That'll really require some re-thinking of how I design databases and code for them...but I know I'll be better off once I make the transition.
Thanks! Rick > -----Original Message----- > From: Chris 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 columns, i.e.: > > Employee_Positions > Position_ID [pk][fk] > Employee_ID [pk][fk] > > > > > ----- Original Message ----- > From: "Rick Faircloth" <[EMAIL PROTECTED]> > To: "CF-Talk" <[email protected]> > 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...such as multiple > > positions for single employees...or perhaps I've just worked around > > it. Now I'll have to figure out how to change my queries to reflect > > the use of this third table... > > > > I guess I just run "regular" insert, add, delete queries on the > > Positions and Employees tables, then when the time comes > > to assign a position to an employee, I'd list the employees, > > select one to the get the Employee_ID, then use a drop down > > of Postions to insert the Employee_ID and Position_ID into > > the Employee_Positions table. > > > > I guess I'd need to add an "Employee_Position_ID" to the > > third table? So it would be: > > > > Employee_Postions > > > > Employee_Position_ID > > Position_ID > > Employee_ID > > > > Is this proper perspective? > > > > 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 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 > > > > etc > > > > > > <or> > > > > > > > Employee_Positions > > > > > > > > Employee_ID > > > > Position_ID > > > > > > > > > > > > It seems like the third table is used to tie the Positions table and > > > > Employees table together, > > > > > > > This may be a poor example of what I'm talking about. > > > > > > It is an excellent example. Just answer the following questions > > > and it should all become clear :) > > > > > > How many positions can an employee have in your first example? > > > How many positions can an employee have in your second example? > > > How many positions can an employee have in your company? > > > > > > Jochem > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:202828 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
