Design question, Does postgres provide a simpler solution than the obvious?

From: Greg Stark <gsstark(at)mit(dot)edu>
To: pgsql-general(at)postgresql(dot)org
Subject: Design question, Does postgres provide a simpler solution than the obvious?
Date: 2002-10-07 22:49:08
Message-ID: 87n0ppg90b.fsf@stark.dyndns.tv
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general


I have a design issue and I know how I would normally solve it, but it looks
to be a pain in the long term. I'm used to Oracle where the right way is
usually the painful way, but being new to Postgres I'm wondering if there are
any special features (perhaps arrays? or rules?) that make this issue easier.

Basically the issue is that the application needs to work in multiple
languages, so every single text field needs to have N different alternate
values. Usually two languages will be inserted and updated together. If the
desired language isn't present I need to default to another language.

So the obvious fully normalized approach is to have a string table and every
simple single query insert and update becomes a more complex transaction that
inserts or updates multiple records in the string table and stores the key for
those strings in the original table.

I guess my ideal solution would allow me to issue an insert or update on the
original table with some sort of associative array data structure as the value
for the string field. The appropriate work would all get done automatically.
Then selects would either return the associative array or perhaps even
implement the entire logic for looking up the correct string to display.

This is a pretty common problem I wonder if anyone has come up with anything
easier to work with than the standard normalized string table approach.

--
greg

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Martijn van Oosterhout 2002-10-08 00:03:08 Re: sloooow query
Previous Message Roberto (SmartBit) 2002-10-07 22:13:01 Re: Postgres for Windows