A recent paper by Jim Gray and colleages from Johns Hopkins University
http://research.microsoft.com/~gray/..._OO_to_SQL.pdf
describes the shortcomings of an OODBMS which they selected some years ago
to process data from the Sloan Digital Sky Survey, and how they were
eventually forced to migrate to a relational DBMS (and chose Microsoft SQL
Server). The OO system they used is, rather tactfully, not named, but can
be discovered from other sources, for example:
http://adass.org/adass/proceedings/adass02/O7-3/

A project that I was involved in chose the O2 product some years ago for
similar reasons, but we are now trying to find an alterative, since after
many corporate take-overs, it is now a "mature product" and not being
actively developed or marketed. The alternative looks as if it has to
be relational (or at least object-relational, such as Postgres). It seems
to me that within a decade, the OODBMS has moved from being the technology
of the future, to being the technology of the past. Rather a pity, I
feel.


--
Clive Page,
University of Leicester, UK.

Hmm, most of them got nothing to do with RDBMS vs OODMS I think.

I wonder if scientific data isn't in a league of it's own. Most commercial
OODMBS's as well as RDMBs's are aimed at the somewhat mainstream data
manipulation.


Take a look at InterSystems Cache.

It seems so, yes.
O2, Versant, ObjectStore, GemStone they all didn't make it for all kinds of
reasons.
Indeed one of the most restricting elements was/is the lack of tools,
specially OQL query tools.

yep

Herman

"Herman Slagman" <herman_slagman (AT) hotmail (DOT) com> wrote

Data is data. There is nothing special about any one kind of data. What is
it about scientific data that makes you think logic does not apply to it?


If you folks had educated yourselves 10 years ago, you would have realised
back then that network model oodbms was very much a technology of the
distant past.


Pity? Good riddance. Apparently, you have not bothered to educate yourselves
even yet.

In article <VIjVa.1382$zZ2.249853062 (AT) mantis (DOT) golden.net>,
Bob Badour <bbadour (AT) golden (DOT) net> wrote:

Well I'm trying (but I'm not a computer person, merely a poor scientist
hoping to get guidance on suitable technology). By the way, if the OODBMS
is such out-of-date technology, I wonder why you still bother to read its
newsgroups.


--
--
Clive Page,
Dept of Physics & Astronomy,
University of Leicester, Tel +44 116 252 3551

In article <1b77ba63.0307282131.36cf6c1a (AT) posting (DOT) google.com>,
johnssk (AT) fishhoo (DOT) com (John Sasak) wrote:

I never understood why they had this emphasis.

Maybe it had something to do with the mindset of people coming from a
data structure rather than data-oriented programming ("business
programming" is not quite the right fit) background.

Last year I was hired to, amongst other things, cleanup an OO-relational
layer that had been written for a startup. It used c++ and mapped to SQL
Server. The guy who wrote it supposedly had 10 years experience writing
such layers and came from a very large organisation.

He thought it was finished when he'd written data access and schema
generation.

There was no concept of searching, declarative or otherwise. All his
examples iterated containers (slowly).

I used to thing OOFILE design was either dumb or heretical, depending on
my mood, but I've always believed that developing database apps is about
collections of data, not individual objects (they are just a collection
of 1).

Talking of declarative systems, how many programmers have you seen doing
partly-declarative work, adding logic to explicitly sort or group data
once the main data retrieval statement has run? I think it's a pattern
than comes from weak API's, some of which are improving.

(and recently going back to a 4th Dimension system I wrote 11 years ago,
I was staggered to see that things like sorting are still not
declarative and you have to trigger sorts after refreshing collections! )

--
Andy Dent BSc MACS AACM http://www.oofile.com.au/
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability

In article <bg5coh$rqe$1 (AT) south (DOT) jnrs.ja.net>, cgp (AT) morpheus (DOT) star.le.ac.uk
says...
He's trying to help the few mis-informed remaining!

----------------------------------------
Paul Tiseo, Systems Programmer
Research Computing Facility, Mayo Clinic
tiseo128.paul23 (AT) mayo (DOT) edu
(please remove numbers to email me)

Again a paper, sponsored by microsoft, which shows the obvious
superiority of microsoft products.
German Kartaster Amt in Bonn, (communal registration of gps coordinates
for traffic signs, borders, buildings....) has a 480 mio entry database,
in which one can hunt for all entries within a radius of 100
meter...postgresql has special features built in to search such things.
Computing time is not measurable, such complex sql statements, like
shown in the microsoft PDF unneccessary.

congrats, microsoft, again you have shown, that MS SQL Server is well
suited even for multi terabyte applications. But still unable to solve
such problems like collisions between simple selects and transactions at
base level, dirty entries at UNCOMMTTED ISOLATION LEVEL, online backup
without getting incoinsistent. How did you backup this terabyte volume ?
Veritas OpenFile Backup ? Online Backup possible ?

regards, Guido Stepken

Clive Page wrote:

Guido,

I added <irony> tags to point out my understanding of your posting, please
correct me where I am wrong.

Guido Stepken wrote:

<irony>


You say that at the Katasteramt in Bonn a system was built with postgres (an
open source RDBMS) that benefits from a proprietary spatial extension holding
480 million entries. The complexity (and probably the poor performance) of SQL
used in the OP's PDF is not necessary.

Am I correct so far?

<irony>

What is the problem here?

- (performant?) select upon 480 million records?
- online backup of a multi-TB system?
- READ UNCOMMITTED and dirty reads? (what's wrong with that?)

Can you elobarate/clarify a bit on the points you made?


Cheers

Gerd
--
Gerd Nachtsheim mailto:gerdn (AT) users (DOT) sourceforge.net ICQ:#13126958

Hi Gerd !

You are right, postgreSQL has some special features for maps, vectors,
3-d cordinates calc....

Backups of multi tera with postgreSQL is no problem, because of MVCC you
have the time it takes to backup a coinsistent snapshot of the database,
*note* while work is still going on. No collisions, locks, speed
decrease ...
SQL Server locks tables and blocks selects while a transaction is still
open. Imagine a dump, nothing else than a long running transaction with
selects over all databases and their tables. If you backup with
TRANSACTION UNCOMMITTED Mode, users can write into some tables and read
from others, while backup is running. So you have dirty entries at the
beginning, and backup transaction hasn't finished yet.
Imagine a second lonng running transaction which start before your
backup transaction, ends after, while a third transaction starts within
you backup. How do you get a checkpoint (state of coinsistent database)
? There will be no time, SQL Server will be coinsistent. So in case of a
crash, you will have to restore your backup, cut some well selected
transactions, insert them into the database and you have to pray, that
you haven't forgotten any data sets.
PostgreSQL with MVCC is coinsistent at any time, because every data set,
every entry has its own version number and - if data has changed during
backup, its own data. Committed transactions in PostgreSQL consequently
reduce the number of versions, a clean up.

Some backup tools stop any queries, wait for all transactions having
finished (this is the reason, why MS sais, transactions have to be
short), make a copy of the whole database. Backup runs then on a copy of
the database, while the original database is released.

regards, Guido Stepken

Gerd Nachtsheim wrote:

You can have both OO and RDBMS in FirstSQL/J ORDBMS. FirstSQL/J provides
integrated support for objects. In FirstSQL/J, table columns can have an
object class as their datatype and mapping is done internally without you
modifying the classes. The value of an object column can be an instance of
its defined class or one of its subclasses.

FirstSQL/J extends SQL to allow you to call the methods of object columns. A
simple
query example:

SELECT shape FROM shape_table WHERE shape.getHeight() < 14;

Object columns have data (fields in the object) *and* behavior (methods in
the object).
Extended object capabilities enhance the strengths of SQL.

Complex relationships can be stored in object columns, but we encourage the
use of
relational facilities for modeling complex relationships. As OODBMS
proponents have
discovered, accessing complex relationships using object structures is too
difficult.

The relational model excels at modeling complex relationships.

Best regards,

FirstSQL Team
"Clive Page" <cgp (AT) star (DOT) le.ac.uk> wrote