1-12 start/2007-02-28/1

I'm sorry I didn't quite follow you here. The database already had made the materialization? We're talking about relational databases there's no concept of materializing an object. I must have misunderstood something about what you were saying. Could you please clarify?

When I talked about this kind of materialization I was talking about the DB engine following relations (joining) and applying restrictions. This is not to be mistaken with the materialization of objects.

That is not completely true - let me be a bit of a troll - imagine for example that you keep an ordered list of orders, using this implementation you could simply do a direct access to the first or last item of the list (depending on how you were ordering it).

Well, introduce me to the persistence framework that does that and I'll take a byte at it. Still, you are still materializing all these objects into memory (because the framework now has the burden of sorting them) to use just one. Even if the sorting is delegated upon the DB engine, you would still materialize an whole set of proxies (at best) to use only just one. Multiply that with your entire result set and there you have it...

Anyway, allow me to provide with yet another example… Say you have a class with a state machine. This class has states s1, .., sn. Now you wish to provide a way for the user to search through your 1e7 records with a criteria that maps to a set of check boxes representing each state. Selecting none searches objects with any state. Selecting some represents the union of states selected.

You can simply add an index on the state, and using the IN operand you get some pretty quick results (the engine is quick to discard unselected states...). Would doing that in memory be anywhere near that efficient?.

And yet another question: say you wish to do paging on the results… Using a parametrized query on the view can quickly discard unwanted results… Doing that in memory can be disgraceful, even only materializing a list of, say, 1000 proxies to use only 20.

My point being, the sum of inefficiencies DDD presents in this field can very well be the deciding factor not to use it in a performance critical environment…