Re: Some thoughts on table inheritance (which is uniquely awesome on PostgreSQL)

> 1) First, in LedgerSMB,

<duck>

What a pity that this is implemented in a write-only programming
language and as a "web application" instead of an actual GUI...

</duck>

> we started using it to create consistent interfaces to sets of
> storage tables. The storage tables would behave differently, but
> would inherit essentially interfaces from their parents. In this
> regard, you can think of an inheritance tree as a partitioned table
> set, but where the partitioning is necessary because foreign key
> fields reference different tables in different children. We use this
> for example, to avoid having to have a global notes table or global
> file attachments table and it gives us clear control over where these
> can be attached along with central maintenance of data structures.
> In cases, like with file attachments, where foreign keys to
> inheritance trees ended up being needed, we started out with a more
> complex but workable solution but I think are going to a simpler one.
> This is a good thing.
>
> In essence what we did was use inheritance to give us variable target
> tables for a foreign key column. I would still like to see
> inheritable foreign key constraints because that would make some
> things a lot easier, but the idea that foreign keys are not, by
> default, copied in, means that you can override the destination in the
> child table. It isn't the use documented but it actually works very
> well.

Is there some documentation (database schema, DDL, etc.) where this is
described in detail?

> 2) Secondly I re-read Stonebraker's "Object-Relational Database: The
> Next Wave" and I had a rather sudden epiphany. Relational databases
> are about modelling your data so you can ensure consistency and gain
> as many answers as you can. Object-relational modelling adds
> interfaces (possibly written in arbitrary programming languages) to
> derive additional information from stored information.

As a non-computer scientist by training, I thought object orientation
from the purely utilitarian point of view would be essentially about
inheriting common features such as attributes, methods etc. from base
classes, respectively base tables in the case of an object-relational
database, to reduce implementation effort for code, increase consistency
etc...

And about "encapsulating" methods (procedures) together with the classes
(tables) that they work on.

> 3) I was talking with Matt Trout regarding object-oriented
> programming in Perl, and he turned me on to Moose::Role as essentially
> an interface class. It cannot be instantiated and one would not
> simply inherit it in order to instantiate it. Rather it provides an
> ability to assemble classes from re-usable pieces and thus provide
> consistent interfaces across a project. This has become a key to my
> understanding of the use cases for multiple inheritance in PostgreSQL,
> namely that you can define interfaces across column combinations and
> combine those column combinations into a table.

What's the difference from the use of custom composite types to
aggregate tables? Except for access syntax?

Sincerely,

Wolfgang