On 11/02/2013 04:58 AM, Francisco Olarte wrote:
On Thu, Oct 31, 2013 at 5:13 PM, Adrian Klaver <adrian.kla...@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.kla...@gmail.com
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
