Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL - Mailing list pgsql-sql

At 02:42 PM 2/4/00 +1100, Chris Bitmead wrote:

>Not true, because if the wrapper conforms to the ODMG standard, it will 
>be compatible with ObjectStore, Versant, the new Sun RDBS standard,
>Gemstone, and many others.

Without prejudice, I'd be interested in some order-of-magnitude 
market share for these technologies vs., say, Oracle.

>The biggest thing you can do for speed is to have less objects/tuples
>in the database. Inheritance and the array feature of postgresql
>can improve things here by orders of magnitude.

There's no doubt of this, for applications that can make use
of the paradigms.


>The problem is that
>these
>two features are not viable to use at present. With an ODMG interface,
>and TOAST to allow tuples of unlimited size this will then be a viable
>feature. In some situations this will improve queries by 100x even
>with the most brain-dead optimizer. ODBMS doesn't care a great deal
>about wonderful optimizers because joins are less necessary.

And this last statement I really have to wonder about.  For restricted
application spaces, yeah, no doubt.  But in general, no way.

>Exactly, so stop mapping things and creating complicated joins. ODBMSes
>do not do ANY joins to re-create objects. That's why mappers suck so
>hard.

If they don't do joins, then presumably they map many-to-one relations
by copying data into each of the "many" table rows.  TANSTAAFL, no?

Though this strategy is a very viable one in today's big-memory, big-disk
environment.  It's not clear to me that a extremely smart RDBMS system
couldn't decide to add redundancy itself and gain much of the efficiency,
but, heck, that's just my weak, uncreative compiler-writer mind at work
again.

(and clearly, of course, PG isn't on any threshold of doing it, I'm 
thinking in theoretical space here).


>Now with an ODBMS, a Car with 4 wheels and a steering wheel we'll have 6
>objects in the database - 1 Car, 4 RoadWheels and 1 SteeringWheel. With
>a relational mapper, depending on how you map it you'll have 21 objects
>- 5 CarPart objects, 5 wheel objects, 4 road wheel, 1 steering wheel, 1
>car and 5 car_carpart relation entities. And when you join it all
>together you'll have to join against 6 tables instead of 3.

Not really.  You'd probably denormalize and not worry about it, in 
practice.

Would the result be as beautiful?  I don't know - do most car designers
think that SteeringMechanism and PavementInterface are the same?  It's
true for a variety of reasons in today's cars that aren't actually
related, and high-end race cars are exploring joystick control.

So one could claim that your hierarchy is merely limiting creative
expression...



- Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, Pacific Northwest Rare Bird Alert
Serviceand other goodies at http://donb.photo.net.