Re: Best Strategy for Cacheing
Re: Best Strategy for Cacheing
- Subject: Re: Best Strategy for Cacheing
- From: James Cicenia <email@hidden>
- Date: Thu, 23 Oct 2008 10:47:27 -0500
Well -
If you totally normalized this in your database it will slow the
database considerably.
However, flat files are fast.
Another alternative might be a true object database.
James
On Oct 23, 2008, at 10:33 AM, David Avendasora wrote:
Two reasons:
1) This is an expensive thing to run and I use it all over the
place. Running it once per session worked, but even that was a lot
of overhead, now using more ECs is only going to multiply the number
of times it's being generated.
2) It would be handy to have access to this "flattened" version of
the part/components hierarchy by reporting software like Crystal
Reports.
I'm _assuming_ that having it stored as data in the DB instead of
having to generate it is going to be hugely faster and the tradeoff
is the complexity of keeping it fresh.
Am I wrong about the trade-off being worth the speed gain?
Dave
On Oct 23, 2008, at 10:33 AM, James Cicenia wrote:
If the data is read only why would you have to change your current
strategy?
Just wondering?
- James Cicenia
On Oct 23, 2008, at 5:21 AM, David Avendasora wrote:
Hi all,
I've got a recursive structure in my model:
Part <->> Routing <->> RoutingStep <->> RoutingComponent <<-> Part
Which could be simplified to:
Part <->> Part <->> Part <->> Part...
So basically, a given part is made up of multiple other parts,
which in turn can be made up of other parts, and so on, and so on.
In theory this nesting can be infinite but in practical terms it
is usually less than 5 levels deep.
The problem is that each part needs to know what all the possible
parts are that go into making it, how much of that component is
needed, which WorkCenter it is used in, on which
ManufacturingLine, etc - no matter how deeply nested they are. The
trick is that there can be different ways of making it on
different manufacturing lines, and other complicating factors.
Simply traversing the object graph and compiling the information
each time I want it is a lot of overhead.
Right now, I simply have an inner class on Part called "Component"
that has all this information and the first time I need the
information for a Part for a given session I generate all the
Components for that Part and then store them in a
NSArray<Part.Component> instance variable on the Part. I use this
information in lots of places. But now that I'm moving to using
multiple ECs instead of the default EC so I'm going to have to do
the work of compiling the list of Components for each EC instead
of once per session.
I think I've reached the point where having the data persisted in
the DB and actually part of the model and therefor managed by EOF
is going to be more efficient. I know I'll have data-freshness
issues with this strategy, but it will also make this data more
easily accessible from the outside of the WO system through things
like Crystal Reports.
I'm wondering what the best way to handle this will be. Am I going
down the wrong road in the first place?
Thanks,
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden