Re: GDL2/EOF scaling (was: Re: GNUstep roadmap)

[Helge Hess]

On 28.10.2003, at 20:52, Patrick Coskren wrote:
...
> > If you have 50.000 person entries with 150.000 address entries you 
> > just cannot afford to load all that as objects into memory just 
> > because you want to display "name", "city" and "street". Objects have 
> > a deep and inherent mismatch with the set approach taken by RDBMS.
> If you've got an app that's loading all those entries at once, then 
> it's a batch app.

It is an absolutely usual situation that you display some few 
attributes of a large table and has nothing to do with batch processing 
(which is working on the whole set of the data).
The mail I write will end up in an IMAP4 folder which has at least 
10000 entries and the UI can deal with such amounts of data just fine 
(since it isn't loading the whole mail but rather queries the subject, 
the sender and the send date from my IMAP server).

> And EOF isn't designed for batch processing.  You're right as far as 
> that goes.

I never claimed that. I'm talking about regular database applications 
and database applications imply that you are dealing with large tables 
(and in the usual case not display just one or two of them at the same 
time ...).

> But in any end-user app, you're only loading a subset of the rows (and 
> probably a small subset at that) into memory.  So the object paradigm 
> of EOF works very well.

No it doesn't. While loading 10000+ rows with 3 or 4 attributes of a 
joined person and address table is a non issue, loading 10000 *full* 
objects is an unacceptable overhead. So you either go down to adaptor 
level or hack-around the issue, eg by introducing artificial entities 
which break the whole object encapsulation and references and is 
awkward for other reasons as well.
And this is just because you want to do a "select a,b,c from d,e where 
d.pkey=e.foreignkey".

> Personally, I found EOF no harder to learn than JDBC, and I was a hell 
> of a lot more productive with it.  YMMV, I suppose.

I didn't deny that EOF lower levels are less productive than JDBC. But 
the reverse isn't really true either (well, JDBC is hit by the fact 
that you need to use it in conjunction with Java ;-)

But to repeat myself: if you are fine with EOF, excellent :-) I have no 
mission to make EOF look bad. It isn't, its very cool technology and I 
love working on that. Yet I personally do not believe that it gives 
anything for the majority of the people - its certainly not killer.
Eg something which got killer not at least by the application of 
appropriate-for-the-task database technology is Zope.

regards,
  Helge
--
OpenGroupware.org
http://www.opengroupware.org/