[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.
regards,
Helge
--
OpenGroupware.org
http://www.opengroupware.org/
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), (continued)
- recruiting (was Re: GNUstep roadmap), Pete French, 2003/10/22
- Environment? (was: Re: GNUstep roadmap), Stefan Urbanek, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/22
- Re[2]: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Manuel Guesdon, 2003/10/23
- Re: Re[2]: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Helge Hess, 2003/10/23
- GDL2/EOF scaling (was: Re: GNUstep roadmap), David Ayers, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Helge Hess, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Patrick Coskren, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap),
Helge Hess <=
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Patrick Coskren, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Helge Hess, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Patrick Coskren, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Helge Hess, 2003/10/28
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Marco Scheurer, 2003/10/29
- Re: GDL2/EOF scaling (was: Re: GNUstep roadmap), Patrick Coskren, 2003/10/29
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Dennis Leeuw, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Richard Frith-Macdonald, 2003/10/22
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), Philip Mötteli, 2003/10/22