NYCPHP Meetup

[Adam Fields]

On Wed, Oct 16, 2002 at 05:40:53PM -0400, Jim Hendricks wrote:
> The other reason for avoiding this is my Host Provider would croak if I 
> build too much in memory thus hogging the memory shared across many 
> sites.  I avoid as much memory use as I can so when I really need it 
> it's available.

Seems reasonable. I don't know how much memory overhead the class
implementation adds. I wouldn't think too much. Anyone?

Even session variables aren't stored in memory though - they're
written out to temp space on disk (at least, that's how I read the
docs).

> Adam Fields wrote:
> 
> >On Wed, Oct 16, 2002 at 04:22:11PM -0400, Jim Hendricks wrote:
> >  
> >
> >>Adam Fields wrote:
> >>
> >>    
> >>
> >>>I'd wrap a class around the whole thing. Use that class to broker
> >>>reads and writes to the tree table. Add a "changed" timestamp to the
> >>>tree, and have a read from the class only reload the tree from the
> >>>database if it's changed since the last read. Stash the object in the
> >>>session for reuse, or serialize it to another table (or file, or
> >>>whatever) for quick retrieval.
> >>> 
> >>>
> >>>      
> >>>
> >>I don't know about the class thing since it adds a level of complexity 
> >>to the code that I don't know
> >>if it's waranted.  
> >>    
> >>
> >
> >I would argue that this will actually make the majority of your code
> >simpler, because you're encapsulating the complexity. :)
> >
> >I'm the first to admit that classes aren't appropriate for everything,
> >but they're the right approach for this kind of stuff.
> >
> >I'd do something like this:
> >
> >class tree {
> >      var nodemap;
> >      # and whatever else you want
> >
> >      function tree () {
> >      # maybe some init code
> >      }
> >
> >      function get_tree () {
> >      # check if tree has changed or isn't populated yet
> >      # if yes to either, get tree from db
> >      # otherwise, maybe get tree from intermediate storage if you're
> >      doing that
> >
> >      }
> >
> >      function save_tree () {
> >      # write tree to db
> >      }
> >
> >      function store_tree () {
> >      # write tree to intermediate storage
> >      }
> >
> >      function render_tree () {
> >      # if tree isn't populated, get tree
> >      # output tree html or tree values or whatever
> >      }
> >      
> >      function get_tree_values () {
> >      # return raw node data for the tree
> >      }
> >}
> >
> >Then, in your page:
> >
> >$mytree = new tree();
> >$mytree->render_tree();
> >or
> >$mytree->get_tree_values();
> >
> >  
> >
> >>I do like the idea of caching the tree though.  I 
> >>would cache it in the DB so that the
> >>tree does not need to be generated at all when the request to display it 
> >>occurs.  The tree would
> >>be regenerated everytime a change occurs to the underlying data ( which 
> >>is a low volume data set )
> >>This may not be a good idea for items that have a higher change velocity.
> >>    
> >>
> >
> >While I wouldn't advocate this approach for something that changes
> >once a minute or so, if it changes less than once an hour, this will
> >probably still result in a performance gain, and it will be easier to
> >maintain.
> >
> >  
> >
> 
> 
> 
> 
> --- Unsubscribe at http://nyphp.org/list ---
> 
> 
> 

-- 
				- Adam

-----
Adam Fields, Managing Partner, fields at surgam.net
Surgam, Inc. is a technology consulting firm with strong background in
delivering scalable and robust enterprise web and IT applications.
http://www.adamfields.com