dbTalk Databases Forums  

Forced migration from OO to relational

comp.databases.object comp.databases.object


Discuss Forced migration from OO to relational in the comp.databases.object forum.

Reply
 
Thread Tools Display Modes
  #1  
Old   
Clive Page
 
Posts: n/a

Default Forced migration from OO to relational - 07-28-2003 , 04:02 AM






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.




Reply With Quote
  #2  
Old   
Herman Slagman
 
Posts: n/a

Default Re: Forced migration from OO to relational - 07-28-2003 , 04:53 PM






Quote:
describes the shortcomings of an OODBMS which they selected some years ago
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.

Quote:
The alternative looks as if it has to be relational (or at least
object-relational, such as Postgres).

Take a look at InterSystems Cache.

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

Quote:
Rather a pity, I feel.
yep

Herman




Reply With Quote
  #3  
Old   
Bob Badour
 
Posts: n/a

Default Re: Forced migration from OO to relational - 07-28-2003 , 06:54 PM



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

Quote:
describes the shortcomings of an OODBMS which they selected some years
ago

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


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

It seems so, yes.
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.


Quote:
Rather a pity, I feel.

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




Reply With Quote
  #4  
Old   
Clive Page
 
Posts: n/a

Default Re: Forced migration from OO to relational - 07-29-2003 , 03:54 AM



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

Quote:
Pity? Good riddance. Apparently, you have not bothered to educate yourselves
even yet.
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


Reply With Quote
  #5  
Old   
Andy Dent
 
Posts: n/a

Default Re: Forced migration from OO to relational - 07-29-2003 , 01:28 PM



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

Quote:
The lack of declarative query language, OQL, SQL, or whatever, has
disappointed developers for the last decade.
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


Reply With Quote
  #6  
Old   
Paul Tiseo
 
Posts: n/a

Default Re: Forced migration from OO to relational - 08-01-2003 , 09:58 AM



In article <bg5coh$rqe$1 (AT) south (DOT) jnrs.ja.net>, cgp (AT) morpheus (DOT) star.le.ac.uk
says...
Quote:
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.
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)


Reply With Quote
  #7  
Old   
Guido Stepken
 
Posts: n/a

Default Re: Forced migration from OO to relational (microsoft sponsoringagain) - 08-04-2003 , 04:50 AM



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




Reply With Quote
  #8  
Old   
Gerd Nachtsheim
 
Posts: n/a

Default Re: Forced migration from OO to relational (microsoft sponsoringagain) - 08-04-2003 , 05:49 AM



Guido,

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

Guido Stepken wrote:

<irony>
Quote:
Again a paper, sponsored by microsoft, which shows the obvious
superiority of microsoft products.
/irony


Quote:
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.
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>
Quote:
congrats, microsoft, again you have shown, that MS SQL Server is well
suited even for multi terabyte applications.
/irony

Quote:
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 ?
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



Reply With Quote
  #9  
Old   
Guido Stepken
 
Posts: n/a

Default Re: Forced migration from OO to relational (microsoft sponsoringagain) - 08-05-2003 , 04:37 AM



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:
Quote:
Guido,

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

Guido Stepken wrote:

irony

Again a paper, sponsored by microsoft, which shows the obvious
superiority of microsoft products.

/irony


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.


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

congrats, microsoft, again you have shown, that MS SQL Server is well
suited even for multi terabyte applications.

/irony

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 ?


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


Reply With Quote
  #10  
Old   
David Morse
 
Posts: n/a

Default Re: Forced migration from OO to relational - 08-06-2003 , 01:03 PM






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

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




Reply With Quote
Reply




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off



Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.