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