On 11/02/2013 04:58 AM, Francisco Olarte wrote:
> On Thu, Oct 31, 2013 at 5:13 PM, Adrian Klaver <adrian.klaver@gmail.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.
I understand the need to generate uniqueness, what I am not
understanding is this method. Table1 is just a series of numbers, so
were is the context that tells you what the numbers mean? To me it boils
down to; if you just want to generate numbers use a sequence directly,
if the numbers have meaning, supply context. Probably have spent too
much time on this already, just one of those things that puzzle:)
>
> Francisco Olarte.
>
--
Adrian Klaver
adrian.klaver@gmail.com