[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] the id_name debate

From: Richard Terry
Subject: Re: [Gnumed-devel] the id_name debate
Date: Fri, 3 Sep 2004 08:31:39 +1000
User-agent: KMail/1.5.4

I remember now why I got the shits with the names just being ID:

It is because, when you are using say a visual designer where you can drag and 
drop the joins (like pgaccess) then you can't tell what foreign key is likely 
(meant to) be linked to what table!

Wheras if the primary key in street table was id_street, and this key is in 
another table you can immediately see what to join.

IMHO I think this is important for ease of use/development/maintainability.



On Fri, 3 Sep 2004 06:04 pm, Horst Herb wrote:
> On Fri, 3 Sep 2004 01:44, J Busser wrote:
> > Does this mean that
> >     if a join should have to operate on 2 tables
> >     selecting from each a field named "id"
> > that the syntax will stumble, and/or it is unwanted/extra work to
> > have to provide aliases so as to be able to distinguish the column
> > names and data from the two "id" fields in the output?
> create table a(id serial primary key, text text);
> create table b(id serial primary key, id_a integer references a(id), text
> text);
> select a.text, b.text from a left join b on (;
> That works. Where's the problem? Whenever there is a identifier clash, all
> you have to do is explicitly name the table (unless you use aliases)
> Regarding the id vs fk debate:
> I recommend that
> - any primary key of a table is named "id"
> - any reference to a foreign key is named id_<tablename>
> Horst
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]