Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL

Don Baccus wrote:

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

Would you be interested in the market share of Win98 compared to Linux?

Nobody uses an ODBMS if they can get it to work with Oracle. They go to
an ODBMS when they realise that's the only way they can get it to work.

However, as I said, Sun is defining for Java a standard interface for
RDBMS which is exactly the same as ODMG. So expect a lot of people using
Oracle to be writing code that ports to an ODBMS. Maybe when they
realise they can slot a real ODBMS under their
app and greatly increase performance, it might be
good for the ODBMS market.

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

To my mind that is like saying OO is useful for programs that can make
use of the paradigms. In fact I think nearly all programs can make use
of OO.

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

It's only when you need a great deal of ad-hoc queries that you really
need a RDBMS. But a very great proportion of apps have only very
specific querying needs, and an ODBMS can do those queries MUCH faster.

And if postgresql has *both*, then it should be the
best of both worlds. I'm not going to go around
claiming RDBMS is obsolete, but I do know that ODBMS
is much more convenient to use for programming. Once
you've done your app and you want to spew off a few
reports, that's when you wish you had RDBMS.

> >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?
^^^ ?

They have a similar layout on disk to what you might have in memory. So
if you store a 1:M in memory as an array of pointers, that's how you
might do it on disk too.

> 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.

Do you mean an RDBMS might try and be smart and store it the same way?
Well if it did that, we might call it an ODBMS. But the other main
benefit of an ODBMS is that retrieving records for many cases
(non-ad-hoc) is very simple to program for because you don't have to map
say a join table into say a C++ List<type>. In
other words it's not just the performance of ODBMS
that is good, but also the interface. Also
if an RDBMS maps an object to a table and then maps it
back to an array on disk, well you've done an
unnecessary conversion.

> >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.

Then what happens to your RDBMSes wonderful ad-hoc query facility if you
de-normalise? Will you have to do a UNION with about 5000 clauses to
retrieve the volume and price of each type of car part?

> 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...

My hierarchy? The point is that you can _have_ a hierarchy. It's well
accepted that OO hierarchies are
good. The good thing here is being able to directly
store it in the database.