Re: design resource

From: Steve Midgley <public(at)misuse(dot)org>
To: pgsql-sql(at)postgresql(dot)org
Subject: Re: design resource
Date: 2008-06-06 14:57:11
Message-ID: 20080606145744.4D4D02E003A@developer.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

At 11:20 PM 6/5/2008, pgsql-sql-owner(at)postgresql(dot)org wrote:
>Date: Thu, 5 Jun 2008 10:14:04 -0400
>From: "Edward W. Rouse" <erouse(at)comsquared(dot)com>
>To: <pgsql-sql(at)postgresql(dot)org>
>Subject: design resource
>Message-ID: <0e9c01c8c716$6f5db800$143c520a(at)ntc2s(dot)comsquared(dot)com>
>
>I was wondering if there were any resources that have some table
>designs for common problems. Since that isn't very clear I will
>give an example.
>
>We have an internal app from years back that needs to be updated. One
>of the problems is that when it was originally created, the
>company only had US customers. We now have international customers and
>need to support international addresses and phone numbers.
>For the phone numbers that means adding a new column for international
>code or expanding the data field so that it's big enough to
>hold the international prefix (still not sure which approach is best).
>But I haven't a clue as to how to set up for international
>addresses.
>
>So I was hoping there would be a resource that I could check where
>these kinds of data sets have been 'solved' to ease the effort. I
>have several books on design patterns for programming but I've not
>seen a design patterns book for common database problems. Thanks.

Hi,

In addition to Craig's excellent answer, I'll give an additional
nuance. I think that free-form and flexible/re-usable fields are the
way to for handling addresses.

However, normalizing country is generally pretty smart (as is
normalizing state/admin region within countries where you do a lot of
business). This can be generally handled on the front-end with a
pull-down menu of choices, but you would probably be happiest enforcing
this on the back-end as well - possibly by having a "country" look up
table:

country_id|iso2|iso3|full_name|short_name|full_accents|short_accents...etc

I keep the country names with and without accents to make searching
easier across keyboards/locales.

I hope this helps too -- I think Craig has given you the lion's share
of good advice for sure - and I definitely follow the practices more or
less as he laid them out as well.

Sincerely,

Steve

Responses

Browse pgsql-sql by date

  From Date Subject
Next Message Chris Preston 2008-06-06 18:33:43 crosstab functions in postgres 8.1
Previous Message samantha mahindrakar 2008-06-06 14:29:43 Trouble with exception