Hi, > I also need the field "lpp_id" as a unique key which is a field that contains a consecutive number of type serial.
Are you sure you REALLY need this? It looks like a lot of trouble for nothing, as you now have one thing warranting the unicity of the record (your serial) plus a unique key warranting you do not couple twice the same language with the same person. Normally, you'd rather have something like (person_id) (language_id) (weight) where the primary key is (person_id, language_id) (hence a simple Cartesian product, both elements of the key being FKs to Language and People, or whatever you call your tables) and weight is outside the key, but used for sorting, so you have a preferred language. What would be the rationale behind the serial number? Cheers Bèrto On 23 July 2013 22:44, JORGE MALDONADO <jorgemal1...@gmail.com> wrote: > I have 2 tables, a parent (tbl_persons) and a child > (tbl_languages_per_person) as follows (a language table is also involved): > > ------------------ > tbl_persons > ------------------ > * per_id > * per_name > * per_address > > -------------------------------------- > tbl_languages_per_person > -------------------------------------- > * lpp_person_id > * lpp_language_id > * lpp_id > > As you can see, there is an obvious key in the child table which is > "lpp_person_id + lpp_language_id", but I also need the field "lpp_id" as a > unique key which is a field that contains a consecutive number of type > serial. > > My question is: what should I configure as the primary key, "lpp_person_id > + lpp_language_id" or "lpp_id"? > Is the role of a primary key different from that of a unique index? > > With respect, > Jorge Maldonado > > > > > > > -- ============================== If Pac-Man had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music.
