composition v. inheritance

From: Tom Strickland <tom(at)stricklandc(dot)demon(dot)co(dot)uk>
To: Postgres Novice <pgsql-novice(at)postgresql(dot)org>
Subject: composition v. inheritance
Date: 2001-06-18 10:01:22
Message-ID: 20010618100122.G1439@lyra.stricklandc.demon.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-novice

For our CRM database, we have a table called 'action', which defines
'time spent by an employee doing something'. The intent is to extend
this table to encompass specific actions, such as time spent training
groups of clients, correspondance on behalf of a client... The trouble
is that simple inheritance probably won't work because of a need for
multiple inheritence. I am toying with the idea of composition, with
another table 'action_composite':

CREATE TABLE action_composite(
action_id INTEGER,
table_ref VARCHAR(20),
CONSTRAINT a_compos_pkey PRIMARY KEY(action_id, table_ref)
);

ALTER TABLE action_composite ADD CONSTRAINT action_id_fk
FOREIGN KEY(action_id) REFERENCES action(action_id) ON UPDATE CASCADE;

I'm not sure about table_ref, but it would either be a reference to
the table's id or a VARCHAR containing the table's name. In this way a
an action in the real world that consists of 'work on a client's
problem' and 'correspondance' can be represented. I am uneasy about
this solution - it feels slightly wrong. Can anyone help?

Thanks,

Tom

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Tom Strickland 2001-06-18 11:27:18 Re: composition v. inheritance
Previous Message Yeo Eng Hee 2001-06-16 01:59:41 OpenSSL problems