Re: Inheritance
| От | Craig Ringer |
|---|---|
| Тема | Re: Inheritance |
| Дата | |
| Msg-id | CAMsr+YE5oNwGr233oKbjC5KPURqDMR4iERZ3mptCh2P+3Y-3TQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Inheritance (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Ответы |
Re: Inheritance
(Jim Nasby <Jim.Nasby@BlueTreble.com>)
|
| Список | pgsql-hackers |
On 24 May 2016 at 21:51, Jim Nasby <Jim.Nasby@bluetreble.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).
В списке pgsql-hackers по дате отправления: