Adrian Klaver-3 wrote
>> Table1
>> Column | Type | Modifiers
>> ----------+-------------------__+-----------------------------__------------------------------__--
>> id | integer | not null default
>> nextval('test_table_id_fld___seq'::regclass)
>>
>>
>> Table2
>> Column | Type | related
>> ----------+-------------------__+-----------------------------__------------------------------__--
>> id_table1 | integer | FK of Table1.id
>> id_lang | integer | FK of lang.id
>> <http://lang.id>
>> name | varchar
>>
The PK for table 2 is composite: the serial key from table 1 + the language
id. The table 1 id has to be able to repeat since the same "entity" needs
multiple translations. Using a serial on table 2 is also possible but a
separate issue and probably not worth adding since you need a unique index
on (id_table1, id_lang) regardless.
The question is why isn't there some kind of identifier on table 1 that
gives you some idea of what the id/table record is for?
David J.
--
View this message in context: http://postgresql.1045698.n5.nabble.com/Table-with-Field-Serial-Problem-tp5776516p5776546.html
Sent from the PostgreSQL - general mailing list archive at Nabble.com.
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
