Re: Object-relational impedence

Tegiri Nenashi wrote:
> On Mar 5, 7:48�am, Marshall <marshall.spi..._at_gmail.com> wrote:
> > The most gratuitous example I can think of was some early
> > EJB containers I played with, back when I was still thinking
> > that ORM was something that could possibly be done well.
> > Against a table of a few hundred rows, one could execute
> > "delete from table". The comparable command through the
> > ORM issued SQL to load every row as an object, then
> > in a loop called obj.delete() which issued a single DELETE
> > statement for that row. It was ten thousand times slower,
> > and that's for only a couple hundred rows. Of course this
> > example is extreme, but it's still illustrative of a general
> > principle.
> >
> > I have *often* seen four and five order of magnitude
> > performance difference between straight SQL and
> > ORM SQL, across a wide variety of ORMs. The
> > very idea of ORM demands it: you have to try to
> > push a whole set-oriented language through a functional
> > interface.
>
> Yep, this is "drive car to supermarket" analogy in Stephane Faroult
> video
> Part 2: http://www.youtube.com/watch?v=GbZgnAINjUw
> It is a recurrent theme of application database performance meetings.
>
> Why set oriented processing is more friendly to optimisation?
> (Contrary to a moronic blanket statement that joins are bad). Because
> there is a little nice algebra behind it, so that optimization is
> essentially algebraic manipulation with query expressions. This is not
> an easy subject to master of course, so why some people have chosen to
> hide their head in the sand of imaginary code reorganisation problems
> is perfectly understandable.

I think SQL itself is a large part of the comprehension problem. In part, it doesn't easily allow one to break the problem down into smaller sub-problems for a mental divide-and-conquer. If the optimizer wants to re-lump it all together internally for efficiency, that's fine, but the query "formula" itself doesn't have to be written as one big lump.

I've been kicking around an experimental relational language called SMEQL (yes a hint of LOR in the name) that is more "programmer friendly" and decomposable than SQL. And its designed to be DBA-extend- able due to its simpler syntax. It is roughly based on IBM's BS-12 experimental language from the early 70's.

-T- Received on Wed Mar 05 2008 - 23:15:04 CET