Re: r there downsides to explicitly naming a pk column xxxx_pk

From: Greg Robson <gregrobson(at)gmail(dot)com>
To: Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, john snow <ofbizfanster(at)gmail(dot)com>, pgsql-novice(at)postgresql(dot)org
Subject: Re: r there downsides to explicitly naming a pk column xxxx_pk
Date: 2017-12-14 20:58:48
Message-ID: CAFjXWtzLeY1+20A5j9ei132JCGd_riAT_9q7JKVEf2fjNUj+UA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

My personal preference is {table_name}_key for primary keys.

Reason 1
Should you use a NATURAL JOIN the common column will only appear once in
the set of returned columns.
http://www.postgresqltutorial.com/postgresql-natural-join/

Reason 2
It removes ambiguity.

"foo.id" can easily be mis-typed as "bar.id" and a query might still run,
with possible nasty side effects. That can catch you out if it has been a
long day!

If you type "bar.foo_id" instead of "foo.foo_id" the query will fail as
table and column do not match.

Reason 3 (a)
It's unlikely that the primary key on a table might change, but I don't
like to tie function (data type, index status) to the name of a column.
e.g. I would never use "unique_email_address" or "text_total".

Reason 3 (b)
A primary key might consist of one column initially, but then might expand
to become a composite key, at that point you have to start renaming columns.

On 14 December 2017 at 20:41, Gavin Flower <GavinFlower(at)archidevsys(dot)co(dot)nz>
wrote:

> On 12/15/2017 09:22 AM, David G. Johnston wrote:
>
>> On Thu, Dec 14, 2017 at 1:14 PM, john snow <ofbizfanster(at)gmail(dot)com
>> <mailto:ofbizfanster(at)gmail(dot)com>>wrote:
>>
>> instead of the more conventional xxxx_id or just id?
>>
>> sorry if this may be a foolish question to some, but i'm trying to
>> think thru
>> a junior colleagues's proposal. the discussion occurred while we were
>> discussing naming our foreign key constraints using the convention
>> "childtable_parenttable_colname_fk".
>>
>> ​Are you talking about the constraint name or the name of the column
>> holding the data?​
>>
>> ​Identifiers in PostgreSQL can only be 64 characters (bytes?) long.
>>
>> If it is the column name I wouldn't get too crazy or people writing out
>> SQL joins manually will be asking you to pay their medical bills...
>>
>> I generally avoid naming any column "id" - tables get short code aliases
>> and those prefix the "id". I then name the column in the FK the exact same
>> name. I rely on system defaults for choosing the names of the
>> corresponding constraints and indexes.
>>
>> David J.
>>
>> I use 'id' for the primary key of the current table, and 'xxx-id' for a
> foreign key.
>
> So it is easy to identify the primary key, and to spot the foreign keys.
>
> Since we know the current table name, it is redundant to name the table's
> primary key with the its table name.
>
>
> Cheers,
> Gavin
>
>
>

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Sharon Giannatto 2017-12-14 21:01:11 RE: r there downsides to explicitly naming a pk column xxxx_pk
Previous Message David G. Johnston 2017-12-14 20:48:56 Re: r there downsides to explicitly naming a pk column xxxx_pk