durusmail: durus-users: OODB vs SQL
OODB basics
2005-10-08
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-09
2005-10-11
2005-10-12
Re: OODB basics
2005-10-11
OODB vs SQL
2005-10-09
2005-10-09
2005-10-09
Re: OODB vs SQL
2005-10-10
Re: OODB vs SQL
2005-10-10
OT: Durus
2005-10-13
2005-10-13
2005-10-13
2005-10-09
2005-10-09
2005-10-09
2005-10-10
2005-10-11
2005-10-11
2005-10-11
2005-10-11
Re: OODB vs SQL
2005-10-11
2005-10-11
2005-10-11
2005-10-12
2005-10-12
2005-10-12
Demo application [was: Re: [Durus-users] Re: OODB vs SQL]
2005-10-13
Re: OODB vs SQL
2005-10-11
Durus basics
2005-10-09
2005-10-09
2005-10-10
2005-10-10
2005-10-10
2005-10-13
2005-10-13
2005-10-13
2005-10-13
Re: OODB basics
2005-10-13
OODB vs SQL
Roger E. Masse
2005-10-11
This is a great discussion.  My knowledge of RDBMS could certainly
use some sharpening since I've not really worked in that world in
several years now and even when I did, I was probably just scratching
at the surface.   Thank you for arguing the counter-point :-)

Rodrigo Dias Arruda Senra writes:

 > But when a query against the structure actually built inside an
 > OODB is not answered by just browsing the object graph, do we have
 > a mechanism equivalent in simplicity to JOINS ?

Yes, I believe that object references can take the place of joins
in OODBs for some set of problems.  For example in one of our
databases we have a data model for a process run which is an object
containing a sequence of process steps.  To get all of the steps
of a particular run with a relational query you might write something like:

    SELECT s.step_id, s.name
    FROM
      step s, run r
    WHERE s.run_id = r.run_id
    ORDERBY s.step_id

....where in Durus this is just run.get_steps().  furthermore, step
objects don't have to have an attribute step_id since it can be
computed from it's position in the reference graph.  run_id on steps?
That's probably not needed either since you started with a run object
in the first place.

 > Going further, Relation DBs are backed by the relational algebra
 > model. Is there an equivalent theoretical model to OODBs ?

David tells me that C.J. Date in his book says that although
relational databases in theory come from relational algebra, most
schemas are broken, because they allow duplicate keys, and other
bad patterns that cause them to be mathematically not relational.

 > I guess we can say that RDB are set-theoretic while OODB are
 > graph-theoretic, but them what are the equivalents to selection,
 > projection and join operators in the OODB realm ?

My take:

selection or selection with projection in relational land is to
enumeration or enumeration with condition in OODBs.  There is no need
for join in OODBs.

Isn't JOIN done implicitly via the WHERE clause?  Is it also
an operator?

   -Roger
reply