Message-ID: <5231D8CB.4030907@nasby.net>
Date: Thu, 12 Sep 2013 10:07:55 -0500
From: Jim Nasby <jim@nasby.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: =?UTF-8?B?xYF1a2FzeiBXYWxrb3dza2k=?= <lukasz.walkowski@homplex.pl>
CC: pgsql-performance@postgresql.org
Subject: Re: Varchar vs foreign key vs enumerator - table and index
 size
References: <3AAC8AFE-E908-4AF7-ACDE-F9461B4A62D1@homplex.pl>
In-Reply-To: <3AAC8AFE-E908-4AF7-ACDE-F9461B4A62D1@homplex.pl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

On 8/31/13 8:35 AM, Łukasz Walkowski wrote:
> 3. And this part is most interesting for me. Columns browser, eventsource, eventtype, devicetype, operatingsystem contain a small pool of strings - for example for devicetype this is set to Computer, Mobile, Tablet or Unknown. Browser is set to normalized browser name. In every case I can store those data using one of 3 different methods:

Sorry for the late reply... the Enova Tools project in pgFoundry has code that lets you create a "dynamic lookup table" that allows for easily normalizing slow-changing data. You could then put a writable view on top of that so that the app wouldn't know the difference. It also has a backfill framework that would help you move data from the old table to the new table.
-- 
Jim C. Nasby, Data Architect                       jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance