Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

"David Cressey" <dcressey_at_verizon.net> wrote in message news:2v2fg.8$Eo3.0_at_trndny02...

> "Cimode" <cimode_at_hotmail.com> wrote in message
> news:1149017607.537595.320820_at_i40g2000cwc.googlegroups.com...

>> Sorry the subject is "Possible bridges between OO programming >> proponents and relational model" .

> OK, back to the topic...

> So far, I've seen several attempts to project the world of objects onto
> the
> world of (persistent) relations. A table row
> contains the "shadow" of an object, projected onto the world of data.

> This sounds like the easy way to go, because the problem of producing a
> decent DBMS based on the relational model has been extensively studied,
> and
> according to some, actually implemented.

> But I think it's upside down.

> I think you have to solve the problem of defining a meaningful and useful
> OODBMS without reference to the relational model. You have to have the
> things you would want in a DBMS, like backups, transactions, concurrency
> management, etc. You might even be able to acheive a certain measure of
> physical data independence. Logical data independence is probably too
> ambitious a goal, without reference to the RM.

1. We have to have the means to identify the things in the repository that we wish to manipulate. We know that prepositional/predicate logic, set theory etc is a very powerful means of expressing that identification.
2. We would like the repository to be able to be persistent.
3. We would like the ability to change where appropriate, the physical representation of the repository and/or the things in it, in order to improve system operation (the storage size of 2, the execution speed of 1 etc) .
4. We would like the means to control concurrent access to things in the repository (transactions etc) .

We need 1-4 regardless of whether we are using an SQL product, or an OODB.

The big problem with the OO model is that some of the properties of an entity in
the repository can be *behaviour* and not mere data items. So to combine the best of the SQL world with that of the OO world, we need to have a model where behaviour and data can exist interchangeably.

The paradigm that IMHO best allows that interchangeability is Functional Programming. FP is quite a cultural move though from embedded SQL, C++ OODBs etc.

Regards,
Steven Perryman Received on Thu Jun 01 2006 - 03:17:04 CDT