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
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 |