From: "Matthew Nuzum" <cobalt@bearfruit.org>
To: <mallah@trade-india.com>
Cc: <pgsql-sql@postgresql.org>
Subject: Re: simple join problem
Date: Wed, 19 Feb 2003 23:25:50 -0500
Organization: Bearfruit.org
Message-ID: <000001c2d898$264d1650$6900a8c0@mattspc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <1130.219.65.252.17.1045713745.squirrel@mail.trade-india.com>
Importance: Normal

It may not be too off topic...

This database structure allows me to have several means of contact for my
each of my customers.  An insert trigger keeps exactly one email address,
phone number and mailing address marked as the primary one for that account.
I use a view to give my easy access to the customer's primary contact
information.

Previously, I used a table structure like this:
  users
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 x|username
  |password
  |firstname
  |lastname
  |billing_email
  |other_email
  |phone
  |fax
  |tollfree
  |cellphone
  |pager
  |billing_address1
  |billing_address2
  |billing_address3
  |billing_town
  |billing_state
  |billing_country
  |billing_zip
  |other_address1
  |other_address2
  |other_address3
  |other_state
  |other_country
  |other_zip

As you can see, there are a lot of wasted fields.  Most of my customers have
just one address, phone number and e-mail on file however, some have
several.

By shifting to this structure, my data is more normal(ized).  There are no
limits as to the depth of contact information I can have about my customers.

--
Matthew Nuzum
www.bearfruit.org
cobalt@bearfruit.org
=20
>=20
> Good to see that you got the answer to ur problem.
>=20
> But i have a question to u.
>=20
> Why at all are you keeping 4 tables and joining them too.
> why not have a single table with all the merged columns?
>=20
> In my place i too have a database stuructue similar to you but lately
> i realized the other option would have been better. becoz for every
> datamining query i am having to join multiple table which is not very
> favourable
> to performance.
>=20
> i know it may not be the proper forum to discuss this.
>=20
> regds
> mallah.