Re: Inheritance

From: Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>
To: Craig Ringer <craig(at)2ndquadrant(dot)com>, Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Jan Johansson <jan(dot)johansson(dot)mr(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Inheritance
Date: 2016-05-24 13:51:43
Message-ID: fe1098ad-6765-9cdb-3833-f6dcf4b0617f@BlueTreble.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/23/16 10:30 PM, Craig Ringer wrote:
> I find it notable that no popular ORM has bothered adopting PostgreSQL's
> inheritance features, and instead just use big left joins or repeated
> SELECTs to implement parent/child relationships, with foreign keys
> enforcing constraints.

Since when do we consider ORMs to be an example of how to do good
database design?

In this case, I'm sure no ORM uses the feature because either the ORM's
authors have no clue it exists (except maybe for partitioning) or
because we're the only mainstream database that has it.

> I consider inheritance mostly useless without the ability to have UNIQUE
> indexes that span a parent relation and all its children. You can use
> them for partitioning only by sacrificing a bunch of integrity
> protection or creating messy chains of FKs between individual partitions.

There's ways around this issue, but I agree that it's a very unhappy
situation right now.

> I'd rather like to quietly deprecate inheritance and eventually remove
> it once we have real partitioning and some time has passed...

IMO that's a very unfortunate attitude to have for the "Worlds Most
Advanced Open Source Database". Now that OO programming isn't treated as
a magic bullet it's proven to be an extremely powerful tool, especially
when used to encapsulate complex data. The
ndarray->Series->DataFrame->Panel inheritance tree is a great example of
this. Feature-wise, we need to be doing *more* of this kind of work, not
less. Lack of support for OO paradigms was one of the drivers for NoSQL.
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Nasby 2016-05-24 13:55:08 Re: PATCH: Batch/pipelining support for libpq
Previous Message Andreas Seltenreich 2016-05-24 13:06:25 Re: [sqlsmith] Failed assertions on parallel worker shutdown