Re: Inheritance Algebra

From: Karsten Hilbert <Karsten(dot)Hilbert(at)gmx(dot)net>
To: pgsql-general(at)postgresql(dot)org
Subject: Re: Inheritance Algebra
Date: 2005-12-23 14:01:49
Message-ID: 20051223140147.GA5629@merkur.hilbert.loc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, Dec 22, 2005 at 05:05:49PM -0700, Trent Shipley wrote:

> On Wednesday 2005-12-21 07:50, Karsten Hilbert wrote:

> > I would assume quite a few people would use table
> > inheritance in a simple way were it available in a more
> > convenient fashion: to transport fields, primary and foreign
> > keys to child tables.
>
> I am not clear on why this sort of scenario benefits more from CREATE TABLE's
> "INHERITS" clause than the "LIKE" clause
Because the inherited fields are aggregated in the parent
table.

Imagine a database:

create table narrative_base (
narrative text
);

create table memo (
author text default CURRENT_USER
) inherits (narrative_base);

create table ads (
fk_campaign integer references campaigns(pk)
) inherits (narrative_base);

... more child tables

... even more child tables

Then we go on merrily inserting all sorts of stuff into the
narrative_base child tables for two years.

Now the boss asks me: "Has anyone ever written anything with
'PostgreSQL' in it in our company ?"

So I go

select tableoid, * from narrative_base where narrative ilike '%postgresql';

et voila. I don't have to remember all the tables
potentially containing narrative and join them.

Now, if this properly transporter primary and foreign keys
to child tables I could add

pk serial primary key

to narrative_base and be done with primary keys for all
children.

Get the drift ?

Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Mike Rylander 2005-12-23 15:08:35 Re: Inheritance Algebra
Previous Message Ragnar 2005-12-23 12:40:24 Re: Stored procedure