[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 20:30:36 +0100 |
On 28.10.2003, at 19:33, David Ayers wrote:
I wasn't sure whether I should reply to this, but since people on
#GNUstep now started to ask me why EOF doesn't scale
;-)
let me give you some from an EOF based app I maintain :
# of EOModels: 8
# of EOEntities in a large model: 165
# of rows in large tables: multiple millions (at some installations)
Yes. I think I made my point not clear enough, of course you can write
scalable applications using EOF - after all you can go down to the
adaptor level if you wish.
(there are of course other pretty big EOF projects (eg HDT which Nat!
works on), and also at least 10 times as many projects as big and
bigger based on "regular" access technology)
The issue is that to accomplish that you must go down a *lot* in the
abstraction, so you basically loose a *lot* if not all of the
advantages of EOF. And I more or less claim (though this is also very
much depends on whether you are a EOF hardcore expert or not!) that for
applications which deals with "usual" RDBMS datasets (which are
*always* 10000+ rows, otherwise the use of an RDBMS in front is clearly
overkill), EOF is way more trouble than gain.
Like with any tool set, you need to chose the correct tools for a
specific task. EOF gives a wide range of tools. If you select the
correct one for the task at hand, it scales rather well.
I wouldn't in general disagree. Strip down EOF to adaptor level and add
some stuff which makes things easier (like an adaptor-datasource ;-)
and you'll have a pretty performant toolset - I really do not disagree.
But on the other side you do not have any "killer" advantages anymore,
its still pretty good and certainly better than most of the raw DB APIs
of other environments.
The reasons why EOF is hyped are mostly (not completely!) the high
level features which are based on the idea to map enterprise objects to
database rows and this just doesn't scale. 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.
And yes, I know about all the hacks to workaround the issue like
artificially creating subset entities etc, this is
a) only available to experts which know the hacks
b) those are hacks which you wouldn't need if you would access RDBMS as
intended
Agreed, in a complex integrated framework like EOF it is a bit more
tedious than the theory sounds, but with language features like
poseAs: nearly the most internal techniques can be adapted to fit your
needs. And when we get that far in GDL2 then we can attempt to find a
superior solution.
Well, as mentioned before I *really* do not want to educate someone
about EOF! ;-) If it does the task for you - fine. I just found out of
me that EOF just doesn't provide me anything I need but in contrary
does a lot of things I certainly do not need.
Now I'm sure that there are DB-tools sets that have better implicit
scaling, and I know that people/companies have developed EOF
extensions that add some asyncronous API that may belong in GDL2/EOF.
Maybe we will see some of those in a GDL2 Additions library someday.
I definitely do not think that in the object-relation mapping area a
lot of products exist which are as good as EOF! (well, I'm no expert on
other products either ;-)
You can basically extend my scalability issue to most other OR tools as
well.
So yes, you can develop non-scalable applications with GDL2/EOF, but
yes, you can make highly scalable applications with GDL2/EOF also.
Sure.
Please lets stop the discussion right here, so while I am open for
further arguments, I do not really think that it takes us anywhere.
best regards,
Helge
--
OpenGroupware.org
http://www.opengroupware.org/
- Re: GNUstep roadmap (was Re: [Suggestion] GNUstep-test for quality control), (continued)
- 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), Björn Giesler, 2003/10/22
- 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 <=
- 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), 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