On Wed, 9 Jan 2002, Rick Emery wrote: > First, you are describing a "one-to-many" relationship, bceasue one "file" > record can be referenced by many "people" records. If this is the case, you > may wish to re-design your tablse such that a "people record" contains a > "file_id" field. You can then do away with the "filespeople" table > altogether. Normalization is a good thing; but not when it is at the > detriment of good design including how one processes it.
That last statement makes no sense. Normalization is good design. To say that there could be too much normalization at the expense of design is a non-sequitur. To the original poster, it looks like your design is just fine. Stick with it. > FYI. Your "filespeople" file indicates that both fields are PRIMARY keys. > That cannot be. Only one field may be PRIMARY. I just now tried it to be > certain. What the heck are you talking about?! Multi-column primary keys are certainly allowed in relational databases. A primary key is simple the set of one or more columns by which any row in a table can be uniquely identified. In the case of the table you're referencing, it is certainly necessary to have both column as part of the primary key, as neither is sufficient by itself to uniquely identify a single row. I'm not sure what you tried but I assure you that this statement works for MySQL, and variants thereof will work for pretty much any RDBMS you care to name. create table test (t1 int not null, t2 int not null, primary key(t1, t2)); -dave /*================== www.urth.org we await the New Sun ==================*/ --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
