From: Ian B. <ia...@co...> - 2003-04-11 19:31:50
|
Okay, I got all confused because both of your first and last names start in B, and when I was first skimming through this I thought one of you was arguing with yourself. But no... anyway, to interject, I still don't feel there's a good use case for multiple keys (except legacy schemas) On Fri, 2003-04-11 at 08:44, Bud P.Bruegger wrote: > If this is your comments table, there are no problems. However, the > problem I try to illustrate uses the following table: > > CREATE TABLE ProjectWorkerComment( > project_id INT, > worker_id INT, > comment_id INT, > PRIMARY KEY (project_id, worker_id, comment_id), > FOREIGN KEY (project_id, worker_id) REFERENCES ProjectWorker); In this example you should have a join, in the spirit of RelatedJoin. Project would have a workerComment method that would return a list of (worker, comment) tuples, and Worker and Comment would have similar methods. So long as a table only contains references to other tables, it should be represented by a Join of some sort, the rows of that table should not be Python objects. After looking through examples, I feel increasingly confident that this intuition is correct -- rows without content of their own are derivative, and should be treated as such. Ian |