Re: Approaches for Lookup values (codes) in OLTP application

From: Decibel! <decibel(at)decibel(dot)org>
To: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
Cc: "James B(dot) Byrne" <byrnejb(at)harte-lyne(dot)ca>, "Richard Huxton" <dev(at)archonet(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Approaches for Lookup values (codes) in OLTP application
Date: 2008-02-23 20:07:29
Message-ID: 7AD65D69-F724-4A71-B234-B5F1D7713899@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Feb 15, 2008, at 1:43 PM, Scott Marlowe wrote:
> Generally speaking, I tend towards using the real value as the key and
> foreign key in lookup tables, but occasionally using an artificial
> numeric key is a better choice.

Something to consider here... any table that will have either a lot
of rows or a lot of "type" fields will likely be better off with a
phantom key (such as a serial) rather than storing text values in the
base table. As an example, we have a 500G database at work that
currently doesn't use any phantom keys for this kind of thing. I
recently estimated that if I normalized every field where doing so
would save more than 1MB it would reduce the size of the database by
142GB. Granted, about half of that is in a somewhat unusual table
that logs emails (a lot of the emails have the same text, so the gain
there is from normalizing that), but even discounting that 75G is
nothing to sneeze at in an OLTP database.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Decibel! 2008-02-23 20:49:19 Re: unnesesary sorting after Merge Full Join
Previous Message jimmy Zhang 2008-02-23 18:40:08 VTD-XML 2.3 released