Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL - Mailing list pgsql-hackers
From | Chris |
---|---|
Subject | Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL |
Date | |
Msg-id | 389B7FCE.6320E3AF@bitmead.com Whole thread Raw |
In response to | Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL (Marten Feldtmann <marten@feki.toppoint.de>) |
Responses |
Re: [HACKERS] Re: [SQL] Proposed Changes to PostgreSQL
(Don Baccus <dhogaza@pacifier.com>)
|
List | pgsql-hackers |
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.
pgsql-hackers by date: