Re: Advice on key design - Mailing list pgsql-sql

From Bèrto ëd Sèra
Subject Re: Advice on key design
Date
Msg-id CAKwGa_8T0H4Mp7=cO2VGiaPdpXJGo33CmUZSe_bVEVJ2Yf7dhA@mail.gmail.com
Whole thread Raw
In response to Re: Advice on key design  (Luca Ferrari <fluca1978@infinito.it>)
Responses Re: Advice on key design
List pgsql-sql
Hi,

It looks heavy, performance-wise. If this is not OLTP intensive you can probably survive, but I'd still really be interested to know ow you can end up having non unique records on a Cartesian product, where the PK is defined by crossing the two defining tables. Unless you take your PK down there is no way that can happen, and even if it does, a cartesian product defining how many languages a user speaks does not look like needing more than killing doubles. So what would be the rationale for investing process into this?

Get me right, just trying to understand what you guys are doing.

Bèrto


On 24 July 2013 10:39, Luca Ferrari <fluca1978@infinito.it> wrote:
On Wed, Jul 24, 2013 at 10:38 AM, Bèrto ëd Sèra <berto.d.sera@gmail.com> wrote:

> What would be the rationale behind the serial number?
>

The serial key, also named "surrogate key" is there for management
purposes. Imagine one day you find out your database design is wrong
and what was unique the day before is no more so, how can you find
your records?
The idea is to have a surrogate key to save you from real world
troubles, and then constraints to implement the database design.

I usually use this convention:
- primary surrogate keys named pk and defined as primary keys
- database design keys named _key and defined with a unique constraint.

Luca



--
==============================
If Pac-Man had affected us as kids, we'd all be running around in a darkened room munching pills and listening to repetitive music.

pgsql-sql by date:

Previous
From: Luca Ferrari
Date:
Subject: Re: Advice on key design
Next
From: Luca Ferrari
Date:
Subject: Re: Listing table definitions by only one command