Resolving a many-to-many relationship

This question isn't specific to SS2000, but since there are many here
familiar with database design I thought I'd ask anyhow.
Imagine these two tables for a company's database in which several
salespeople work together on any particular order:
Salespeople (EmployeeID, Name, Location)
Orders (OrderID, items ordered, salespeople involved)
I realize there are problems with repeating groups, but what I'm interested
in is resolving the many-to-many relationship. Each salesperson gets credit
for many sales, and each sale has many salespeople associated with it.
That's a many-to-many relationship, right? As I understand things, a
"composite table" is needed to break down the one many-to-many relationship
into 2 one-to-many relationships. Am I right so far?
I'm stumped as to what composite table I need. Any ideas?
JoshYou could create a table that would store the EmployeeID and the =OrderID. These columns would be the composite primary key and they =would be foreign keys to the respective tables.
-- Keith
"Josh Meyer" <jmeyer@.msg.ucsf.edu> wrote in message =news:uqLjbh1YDHA.3444@.tk2msftngp13.phx.gbl...
> > > This question isn't specific to SS2000, but since there are many here
> familiar with database design I thought I'd ask anyhow.
> > Imagine these two tables for a company's database in which several
> salespeople work together on any particular order:
> > Salespeople (EmployeeID, Name, Location)
> Orders (OrderID, items ordered, salespeople involved)
> > I realize there are problems with repeating groups, but what I'm =interested
> in is resolving the many-to-many relationship. Each salesperson gets =credit
> for many sales, and each sale has many salespeople associated with it.
> That's a many-to-many relationship, right? As I understand things, a
> "composite table" is needed to break down the one many-to-many =relationship
> into 2 one-to-many relationships. Am I right so far?
> > I'm stumped as to what composite table I need. Any ideas?
> > Josh
> > >