Sure -
Sizing:
A typical user will mostly be in one portfolio. A portfolio can have
hundreds of projects. Of course
a user can switch portfolios. This is all in the session. Of course
we have a couple dozen companies
who use the application, so, there can be quite a lot of objects in
memory, I think.
So say for arguments sake 200projects * 3 portfolios * 20 Customers =
12,000 project objects.
Frequency:
Well every time a user switches a page it is making a request.
Relative Size:
hmmm, say the current 200 projects would return 6 different breakdowns.
For instance... a project has a workFlowState and a corresponding
lifeCycleState.
These are regular string attributes of the project object. So, I need
to show a lot of:
wfs1 + wfs2 + wfs3 (worflowstates) or
lcs1 - wfs1
etc.
4) two to four normally
5) mySQL ?? Just figured the whole round tripping, jdbc handoff,
etc., would be worse
than letting EOF do as much as possible in memory. Thus the origin of
my question.
- James Cicenia
On Jan 13, 2006, at 9:59 AM, Ken Anderson wrote:
James,
In my opinion, the answer depends on a number of factors:
1. The size of the total set of data you're managing
2. The frequency of requests
3. The size of the requests results relative to the total data set
4. The number of queryable attributes you might filter on
5. The performance of your database back end
Also, in general, if EOF CAN handle it, I usually let it, and make
sure that I've bumped up faulting amounts so that I minimize round
trips.
Can you give us more detail?
Ken
On Jan 13, 2006, at 10:49 AM, James Cicenia wrote:
Hi -
I am getting a lot of requests for all these queries/fetches. I
was wondering
that since the original set of projects will always be faulted in
based upon
the relationship of Portfolio -->> Project, I was wondering if it
would be faster
to just filter the existing array or to create a new database fetch?
Also, are NSSet operations fast or slow? Could I just create sets
(views) of
the objects and then just union/intersect/subtract these sets??
Any comments would be appreciated.
- James Cicenia
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/lists%
40anderhome.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
