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
