Content-Type: text/plain;
  charset="iso-8859-1"
From: Josh Berkus <josh@agliodbs.com>
Organization: Aglio Database Solutions
To: Tm <x@Vex.Net>, Michael A Nachbaur <mike@nachbaur.com>,
	pgsql-sql@postgresql.org
Subject: Re: Object-Relational table design question
Date: Wed, 18 Jun 2003 08:07:12 -0700
User-Agent: KMail/1.4.3
References: <200306170857.26558.mike@nachbaur.com>
	<200306170923.34974.josh@agliodbs.com>
	<200306180920.44304.x@Vex.Net>
In-Reply-To: <200306180920.44304.x@Vex.Net>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Message-Id: <200306180807.12360.josh@agliodbs.com>

Tm,

> This would work though it's not very scaleable. Our current system makes
> all elements of a service into what we call an 'attribute'. The
> attributes are defined in a table, and attached to each account type,
> and turned on or off, and twiddled with various definitions such as
> term/period billing, etc. This makes it relatively easy to add new
> services... just add another entry in the account attributes table,
> whereas with hard coded joins above, if you add more services you're
> going to have to edit all of your code where joins take place.

Yeah, that's a very good approach.   I use it for any client where they need 
to be able to add new "attributes" and services after the system is built.

It also works for other things ... for example, a "skills" list for an HR 
database.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco