> It's only a better style if it's correct. Now look at a Project Communication
> and a Customer Communication to see if there are any differences in attributes.
> One possible solution is to create a super/sub type entity on the Communication
> entity. One subtype called Customer Communication would have a relationship
> to Customer, and the other subtype, Project Communication would have a relationship
> to Project.
Ok, I had something like that doodled here on my sketchpad :-) But
it's necessary for a communication to be linked to a project as well
as a customer. (Bernard: thanks for your suggestion, I agree that in
some cases that's possible, but in my case the projects are of thus
size, that a customer will not have concurrent projects running, thus
they will always only communicate about 1 specific project)
So how would I translate the super/sub solution to real tables? As I
currently understand it, no matter how I do it the table will have to
have a customer_id and a project_id field, thus creating circularity
in my diagram, correct? Or am I missing something here?
Thanks again for your help, Jonck
Received on Tue Jan 20 2004 - 15:28:47 CST
