I have 3 main top level entities:
Project (PK: Id)
Owner (PK: Id)
Product (PK: Id)
Here are the rules:
A Project can have many Owners. An Owner can have many Projects.
A Project can have many Products. A Product can have many Projects.
This is the part that is confusing me:
A ProjectOwner can have many ProjectProducts and a ProjectProduct can have many ProjectOwners.
Here is how I currently have it setup (w/ two additional tables besides the ones above):
ProjectOwner (PK: ProjectId, PK: OwnerId)
ProjectProductOwner (PK: ProjectId, PK: ProductId, PK: OwnerId)
I am trying to figure out if I am following best practice with this because something seems strange. For some reason I feel like I should have this broken out into 3 tables (ProjectOwner, ProjectProduct, ProjectOwnerProduct).
Just to give you an idea of how things will be saved in the application it will be as follows:
User creates a Project. User creates Owners and during this process they add them to the project. User adds multiple Products to the Project and associates them with Project Owners from the previous step.
Best Answer
It looks like you're almost where you want to be. I typically design those linking tables a bit differently, as well, because I don't like compound PKs and that may not be a "best practice" as much as a personal preference:
Primary Tables:
Linking Tables:
And now let's put some data in...
And now let's link these together.
So now you can link a product up to a project and from there down to the owners or vice versa.
This gives us :
Similar queries can reverse that to show the owners and their products or other combinations. Some XML work can be used to turn this into comma-separated lists instead of more rows...