From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> |
Cc: | Yostin Vargas <yostinv(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Table with Field Serial - Problem |
Date: | 2013-11-02 11:58:25 |
Message-ID: | CA+bJJbw5tTBpChfAKPAOgK5H1c0a5Cfva9zUyVapBRDCq697JQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Thu, Oct 31, 2013 at 5:13 PM, Adrian Klaver <adrian(dot)klaver(at)gmail(dot)com> 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
>>
>
> I may be having one of my dumb moments, but what does the above accomplish
> that including the serial column in Table2 does not?
The default constraint puzzles me a bit, but you can have duplicate
values in table2 and check they are in t1. Imagine something like
this. You store message ids and translations. When a new message is
needed you insert it into t1, put this id wherever it's needed, and
comunicate the id to the translators, which then can insert the
translations in t2 at their pace. It has it uses.
Francisco Olarte.
From | Date | Subject | |
---|---|---|---|
Next Message | Adrian Klaver | 2013-11-02 14:07:23 | Re: Table with Field Serial - Problem |
Previous Message | DT | 2013-11-02 05:33:06 | Why release index relation lock |