Re: more dimensional method like a query...

Responding to Pi421...

the bottle neck is the database... and the middleware the data is
passed thropugh. I need to work with this... :(
I have 64 Combinations.
first attribute with any value * 4 secsond Attribute with any value = 4
* third attribute with any value = 16
* fourth attribute with any value = 64
so there are psossible 64 combinations  of the attributes...

If I understand this properly, each of the four attributes has 4 possible values and the client will ask for an arbitrary combination of the four attribute values. Is that correct?

And at the beginning I need to store the stock depending on every
attribute and than i want to ask getStock (4 Attributes)
How to save the stock? And how to implement the getStock...
Ans i because of database and middleware i need to cache the stock....


In that case, I would encapsulate the [Stock] objects in a persistence 

access subsystems so that they can be read once at startup and are kept
in memory.  Then method that Client accesses would be an subsystem
interface method and that method would dispatch to the appropriate
collection class within the persistence access subsystem that
corresponds to the R1 collection above.  The decouples the persistence
access optimization from the problem solution because Client invokes
the
same interface whether the Stocks are cached or not.

would be nice, but not with 64 subsystems and collection calsses??

I think I agree with Parker (if my understanding above is correct). All you need is an efficient <single> collection class. Since the data is read from the DB once, each Stock is then added to the collection class and the ordering is fixed in the collection class structure. For 64 combinations a balanced binary tree should be good enough but you could use something more exotic like a B-Tree to reduce the search levels if performance was super critical.

[If there are only four possible values for each attribute, then they can be coded in the range 0-3 and you could use a direct table lookup of an 8-bit index (two bits for each attribute) to completely eliminate the search. The key coding is more overhead for the initial setup and you need a 256 entry address lookup table but it could be worthwhile if you access the same objects repeatedly because the "search" becomes a single table lookup in an array of pointers. This sort of optimization is exactly the kind of thing one wants to encapsulate in a subsystem.]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH



.