Re: Inheritance
| От | Craig Ringer |
|---|---|
| Тема | Re: Inheritance |
| Дата | |
| Msg-id | CAMsr+YEFtDCe7KjaRDDa17Dtdc=qhxJi9z-DjB1aYOLLS70gyg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Inheritance (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Ответы |
Re: Inheritance
(Jim Nasby <Jim.Nasby@BlueTreble.com>)
|
| Список | pgsql-hackers |
On 26 May 2016 at 01:56, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
On 5/24/16 8:52 PM, Craig Ringer wrote:
> 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.
How is it less useful than that? To me, the FK "solution" is the absolute worst of everything: you still have all the separate child tables that you must explicitly query *and* you have to get all the joins correct as well. And hope it doesn't have horrible performance.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.
Which is a decision people have come to regret, because then your codebase somehow has to deal with 38 different versions of what a "customer" is.
Oh, I totally agree there. It's almost as bad as people serialising Java objects into the DB. Ugh. It's a bad, bad idea.
It's also what people seem to want to do, and I understand that somewhat given the pain involved in full table rewrites under extended locks and the hoop-jumping required to avoid them. It's particularly painful with something app devs tend to need, but RDBMS designers prefer to ignore: user-defined columns/attributes. Find me someone who *doesn't* want the ability for their app users/deployers/etc to add arbitrary attributes to customer records etc w/o code changes. jsonb helps a lot there, but you lose Pg's type system and have to use a different query syntax etc.
Lower-pain ways to make schema changes and blend dynamic columns (application-user-defined columns) with normal columns would help a lot there. A pseudo-column that can store a TOASTable record extension that's a set of colname/coltype/coltypmod . Storage is the relatively easy bit though, the problem is how to work with that though the planner and executor and output useful results...
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 don't see why we can't do both. There's many cases where more flexibility in what output tuples look like would be very valuable. The JSON features are one aspect; crosstab is another.
Agreed. A real PIVOT, especially one we can use as a source of tuples for subqueries etc, would be really useful and is the sort of thing we'd need some degree of dynamic column handling for.
Postgres is well past the point where our relational features are the big selling point. It's now about scale, an incredibly robust storage engine, and all the extensiblity opportunities. We've moved from being an RDBMS to being a "Data Platform". Improving our OO capabilities just continues that.
Right. I'm just not convinced table inheritance is a useful part of that picture.
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Tom LaneДата:
Сообщение: Re: pg_bsd_indent - improvements around offsetof and sizeof