persistent objects vs. relational (was Re: propel)

Top Page

Reply to this message
Author: Andy Sy
To: True Computer Science Mailing List, PHP Web Development
Old-Topics: Re: propel
Subject: persistent objects vs. relational (was Re: propel)
(cross-posting to ph-compsci because I believe the OO versus
relational issue is of general interest)

(this message sat in my outbox for 2 years, was reluctant
to post it 'coz i might be talking over my head, but after
reviewing it now, i think i might have had a point back
then, and more more importantly, i need to clean up my
outbox ;-) )

Looking at

Propel is apparently modelled ("a port of" the docs claim)
after Apache Torque.

Anyway it sounds very much like what Zope's ZODB (Zope Object
Database) is all about which is the idea of persistent objects.

In essence, you use an (ostensibly SQL-based) RDBMS to store
your object state persistently (i.e. to disk instead of RAM)
and interact with these data using your programming language's
OOP facilities instead of relational ones (SQL queries).

One concern is performance. How efficient is the Creole
layer (and why didn't they just reuse ADODB)? and also keep in
mind that Propel adds YET another layer (with the performance
drag it implies) on top of Creole.

The other concern is what do you gain with OOP facilities
versus SQL queries? (The bashing of OO versus relational for
persistent data access is particularly intense over at

One advantage is supposedly simpler syntax. But then, don't you
also lose a lot of SQL's strengths since OO is actually a lot
less powerful and more verbose than the relational calculus?

Looking at

I don't see much improvements in syntax and little to no
reduction in verbosity (if not worse than before) and you
can see that it still relies on invoking SQL queries for
anything other than the simplest kinds of criteria selection.

I myself believe that the current way of RDBMS<-->programming
language interfacing can stand to be improved greatly. There
is indeed an 'impedance mismatch' between programming language
syntax and the handling of relational data stored in DBMSes.
Dealing with data retrieved via queries on relational tables
is not as straightforward as can be expected. However, it is
a delusion to think that exposing relational data via an object
model is an answer.

First of all, one must realize the distinction between making
programming language objects persistent (and storing them in
an RDBMS or whatever) vs. exposing/wrapping relational data as

While the first is probably desirable, for the latter, I believe
OOP is too conceptually impoverished to make a good 'wrapper' over
relational data. You lose all the elegance and semantic richness
of the relational calculus when you do that and end up having to
re-implement what was formerly expressible (and very elegantly so)
in a relational language with a lot of awkward method calls, or...
you end up embedding SQL (or other relational language) statements
anyway, defeating the whole purpose of having a layer in the first

Andre John Cruz wrote:

> well i share the same sentiment as andy...i like adodb and i wouldn't
> want to go use another unless there's a really good reason :)
> /andre

True Computer Science Mailing List
compsci@??? (#CompSci @
Searchable Archives: