Re: Inheritance

On 24 May 2016 at 21:51, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com> wrote:

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

I don't, but I do consider them a useful measure of what the majority of
users in the field are seeing and doing.

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

Absolutely, and I use OO heavily. But a half-assed "object relational"
feature in the database that only kind-of works isn't OO, and it's
generally less useful than using existing relational-to-oo modelling
techniques like FK-related 1:1 child tables for specialisation.

I'm so sick of seeing "object relational" in PostgreSQL's tagline. It's
nonsense. We do so much so well, why focus on this bogus half-feature so
much?

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

I agree.

Note that there was enough enthusiasm to adopt whole new database engines,
but not enough to use PostgreSQL's existing features for that. Partly
because they suck. In particular, people looking for this tend to want to
be able to create new subtypes without having to mess around making schema
changes and modelling everything.

There's much more future in improving document-structured storage like
jsonb, and possibly extending in future toward hybrid storage with some
normal cols and some dynamic cols, than with Pg's pseudo-object-relational
inheritance feature.

I really wish we could just remove it. I know it's impossible because it's
used for partitioning and because there's a significant and important,
albeit tiny relative to total users, group who're utterly reliant on it for
their DB schemas. I know of one health engine provider who uses it heavily
for example. It's a pity, because deleting the complexity around
inheritance entirely would simplify a number of useful features. I'd
certainly be in favour of allowing new PostgreSQL features _not_ to support
tables with inheritance, making it a semi-deprecated feature that new
functionality doesn't have to support. (I know that goes against the usual
way of things, and I'm usually really against introducing things where X
works unless you have Y or A enabled or it's a full moon on a Thursday, but
IMO the benefit justifies the cost for making inheritance support optional).

--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services