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

From Chris
Subject Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL
Date
Msg-id 389B8250.EB7CF08A@bitmead.com
Whole thread Raw
In response to Re: [SQL] Re: [HACKERS] Proposed Changes to PostgreSQL  (Marten Feldtmann <marten@feki.toppoint.de>)
List pgsql-general
Marten Feldtmann wrote:

>  Hmm, and yes one may find problems where the pure
> relational system is 100x faster than your ODBMS.
>
>  After doing a project with VERSANT and VisualWorks
> (election projection system for the first television
> sender here in Germany) I like the idea of OODBMS,
> but I've also noticed, that they are  not the
> solution to all problems.

Give me a clear application spec and VERSANT, and I will ALWAYS flog
Oracle into the dust. But...

Where SQL comes into it's own is _conveniently_ doing queries that I
never thought of when I first designed my app. Of course many ODBMSes
have SQL or similar too.

>  Joins per se are not that bad .. it depends on when
> and how they are used and how good the analyzer of
> the database is and how good he uses the indices to
> get the job done.

Take the simple SUPPLIER, PART and SUPPLIER_PART situation. The very
fact that you've got an extra table here means you've got to touch many
more disk pages and transfer more data. An RDBMS just can't win when the
ODBMS data model is designed right.

>  One very good point is the query language of the
> rdbms systems. On the odbms side no standard is
> really available, which can be seen as the sql of
> the odbms.

There is a standard called OQL which is very similar to SQL. It's just
rather poorly supported.

--
Chris Bitmead
mailto:chris@bitmead.com

pgsql-general by date:

Previous
From: davidb@vectormath.com
Date:
Subject: Re: [GENERAL] using ID as a key
Next
From: Ed Loehr
Date:
Subject: Re: [GENERAL] using ID as a key