Hi all,

one question .. OODBs are less and less alive in terms of
* newsgroup traffic
* attention
* new products and so on
So it seems they are not the prime hope and not many big
organizations will push them

But anyway there are application cases where a page server
OODB must be superior to any RDB .. e.g. large amounts
of vectorized data like in Geo Information Systems that
are basically graphs where you want to navigate along edges
and have huge amounts of data

Not the prime use case for RDB - looks more like an e.g. the
prime case for Object Store use

Question: What do the Geo Information Systems guys use as their
databases?
* RDBs with performance problems
* RDBs which extensive tuning
* OODBs anyway - despite the fact that they are a bit off the mainstream
* a mixture of RDBs and BLOB data
* what else?

Thanks

Wolfgang

"Wolfgang Keller" <wk (AT) objectarchitects (DOT) de> wrote

That's quite a leap of faith. What makes you assume it would be superior?


That shows quite an interesting bias.

"Wolfgang Keller" <wk (AT) objectarchitects (DOT) de> wrote

Performance-wise OODBs offer no advantages over RDBs. OODBs can simplify the
mapping required between an OO programming language/environment and the
database but this often results in a very naive mapping strategy. RDBs are
at least equally efficient for storing large BLOBs of data. Storing them
normalized (relation-wise) may degrade performance for plain
storage/retrieval but can increase performance of selective retrievals
immensely.

IMHO OODBs are not very usefull. An OR-mapping tool (Entity Beans, JDO) can
be of use but should be applied with care also.

Regards,

Silvio Bierman

if you have let's say 4K page size and if a node of a graph
has let's say 100 Bytes then a page could hold about 40 nodes of a graph.
You can navigate in these without going back to physical storage ...

In RDB's you need to do a lot to get such a behavior for tree-like
and graph like data ...

Hence ... there are applications, where access characteristics give
OODBs an advantage - and as much as I know about Geo Information
systems they could be a candidate

And that's why I ask what these guys use nowadays ..

"Wolfgang Keller" <wk (AT) objectarchitects (DOT) de> wrote

No, you don't. Asserting something does not make it true; even if you are
repeating something you have heard many times.


Since the base assumption is false, your conclusions are suspect.

Ok... I'll bit. How would you set up an RDB to store a tree-like graph so
as to minimize I/O?
Same parameters: 100 byte nodes and roughly 40 related nodes read with one
disk I/O.

I'm not trying to start a flame war ... I'd really like to know how you
would do it.
--
Bob Nemec
Northwater Objects

"Bob Nemec" <bobn (AT) rogers (DOT) com> wrote

It makes it easier to discuss things if people include the attributions.

To answer your question: I would physically cluster the nodes according to
the usage pattern.

"Bob Badour" <bbadour (AT) golden (DOT) net> wrote

references to its related nodes and the page storage pattern would reflect
the usage pattern (or it could be explicitly set by the application ... like
with GemStone cluster buckets). With an RDB I'm assuming a node would be
represented by rows in one or more tables. So, if I have a cluster of 40
related nodes, how do I avoid the table I/O for the join?

And yes, we are dealing with a trivial example.
--
Bob Nemec
Northwater Objects

"Bob Nemec" <bobn (AT) rogers (DOT) com> wrote

The same physical artifact an ODB would consider a node.


Yes, as I said, I would physically cluster the nodes according to the usage
pattern.


Don't assume.


By physically clustering the related nodes according to the usage pattern.
Why do you demand I repeat myself?

Most of the GIS systems out there use RDBMS. The major players are:

ESRI - Oracle, DB2, MSSQL, etc...
MapServer (open source) - PostgreSQL

There are a couple of indexing options available (e.g. grid indexing for
raster type objects, allowing one to spatially divide your features
(objects) into multiple grid levels).

The nature of GIS application are very different from data driven
applications and their tunning methdology centralized on how to effectively
use RDBMS to minimize the number of features (objects) returning from the
underlying RDBMS when using maps as the primary user interface. You'll be
suprise that graph traversal is not such a common thing in GIS as compare to
putting the icon on the map (which is the majority of what GIS application
does).

Hope this clears up some of the GIS and RDBMS relationships.

"Wolfgang Keller" <wk (AT) objectarchitects (DOT) de> wrote