[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Helge Hess
Subject: Re: GDL2/EOF scaling (was: Re: GNUstep roadmap)
Date: Tue, 28 Oct 2003 21:11:36 +0100

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]