Re: design resource

Поиск
Список
Период
Сортировка
От Steve Midgley
Тема Re: design resource
Дата
Msg-id 20080606145744.4D4D02E003A@developer.postgresql.org
обсуждение исходный текст
Ответ на design resource  ("Edward W. Rouse" <erouse@comsquared.com>)
Ответы Re: design resource  (Craig Ringer <craig@postnewspapers.com.au>)
Список pgsql-sql
At 11:20 PM 6/5/2008, pgsql-sql-owner@postgresql.org wrote:
>Date: Thu, 5 Jun 2008 10:14:04 -0400
>From: "Edward W. Rouse" <erouse@comsquared.com>
>To: <pgsql-sql@postgresql.org>
>Subject: design resource
>Message-ID: <0e9c01c8c716$6f5db800$143c520a@ntc2s.comsquared.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



В списке pgsql-sql по дате отправления:

Предыдущее
От: "samantha mahindrakar"
Дата:
Сообщение: Trouble with exception
Следующее
От: "Chris Preston"
Дата:
Сообщение: crosstab functions in postgres 8.1