On Aug 27, 2012 12:58 AM, "Wolfgang Keller" <feliphil@gmx.net> wrote:
>
> > 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>
Actually this has continued to remind me how ugly HTTP is for actual application programming. There are areas where we'd have far improved performance --- including db performance ---if it was in a GUI...
<snip>
> >
> > 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.
>
Accidently deleted your question about docs (on phone, travelling) but answer is it is in the ddl docs but probably needs more detail.
>
> 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...
>
I am also not a computer scientist by training but I dont see anything wrong with that.
I would add that in all cases interface is key and what OOP does is tie procedure and structure together for interface purposes. Whether this is always good or not is an open question.
> And about "encapsulating" methods (procedures) together with the classes
> (tables) that they work on.
>
The big issue is that inheritance gets "sticky" when modelling information rather than behavior and it is all too easy to create ambiguous fkeys (a relational antipattern) which are difficult to enforce and make a mess of things...
>
> What's the difference from the use of custom composite types to
> aggregate tables? Except for access syntax?
To make composite types work gracefully you really want to give them methods and access based on that. With inheritance the type gets inlined in the table. This makes it easy to access via standars relational tools.
Also composite types do not provide centralized chack or not null constraints...
So the access syntax difference is significant but so is the operation.
Best Wishes,
Chris Travers
>
> Sincerely,
>
> Wolfgang
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
