Re: Does it make sense to have 2 unique keys in one table?

In article <umholme0-1110950744420001@dyn1-061.cc.umanitoba.ca> umholme0@ccu.umanitoba.ca "Douglas Holmes" writes: <snip> > When I teach keys, I cover - > key - determines another value > superkey - determines all values in a single row > candidate key - a minimal superkey (which the original example violated) > primary key - the chosen candidate key > foreign key - a primary key value residing in another table And it is perfectly proper for there to be two UNIQUE keys on a table. Take a table listings items in a menu with numbers to order them by: mnu_code char( 10 ) # menu seq_no smallint # item sequence opt_code char( 10 ) # item value Here is is proper that i) each seq_no occurs once only for each menu therefore mnu_code, seq_no is a unique key, and ii) each item will appear once only any menu therefore mnu_code, opt-code is *also* a unique key. In this case it's a bit of a toss up as to which is the primary key - pribably mnu_code, opt_code as both mnu_code and opt_code happen to be foreign keys. -- ============================================================================ Sally Woolrich | This mail contains my personal sally@excelsis.demon.co.uk | views not those of my employer! ============================================================================