NYCPHP Meetup

[Jim Hendricks(Biz Computing)]

This looks to be a simple answer, question is how much memory does it 
consume when dealing with larger amounts of data.  By being able to draw 
the list directly from the result sets, the only memory you are 
consuming is the result set cache's which should not be the whole 
resultset, and the memory for caching the resulting page.  With this 
solution you have all the results held in memory twice, once for 
manipulation, the second for the display cache.

The other thing is for my use, the manipulation would also need to 
include a sort so that your data would display as:

Servers [ID 7] 
- Development [ID 8] 
- - Home Directories [ID 11] 
- Live [ID 10] 
- Staging [ID 9] 
Websites [ID 1] 
- mySQL.com [ID 3] 
- PHP.net [ID 2] 
- - Manual [ID 4] 
- - - Comments [ID 6] 
- - - Functions [ID 5] 

I'll have to look at this further, see if it might be the solution, or part of it.  Thanks.



max goldberg wrote:

>I wrote something similar to what you are describing for a personal 
>project a while back. On the SQL side it's a pretty simple layout,
>every record has a parent id, and from that I can figure out all the 
>children by making a quick and dirty index before hand.
>
>Check out (sorry if the url offends) 
>http://www.fuck.org/~max/traverse.phps for the example
>and http://www.fuck.org/~max/traverse.php for the output.
>
>Sorry if the code is a bit dirty, it's kind of old. =)
>
>-Max
>
>Jim Hendricks wrote:
>  
>
>>I know this is a SQL question, but since most apps deal with SQL, I 
>>figured I'ld ask here since the app is using PHP and MySQL.
>>
>>I have a table that establishes an entity that may have a parent from 
>>the same table.  I would like to display the data in a tree format where 
>>all items with a ParentID of 0 ( no parent ) are listed with children 
>>indented under the parent.  The nesting can be infinite, but 
>>realistically will only be 2 or 3 levels deep.  I can see how to do this 
>>through a whole series of queries, but can see how the performance of 
>>such a design could be very poor if there is a lot of items.  Looking 
>>for any ideas, even if they would require a table design mod to make the 
>>queries simpler.  The current design is a single table with ID, and 
>>ParentID and whatever other info needed for the item.
>>
>>Thanks, Jim
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>    
>>
>
>
>
>--- Unsubscribe at http://nyphp.org/list ---
>
>
>
>
>
>  
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nyphp.org/pipermail/talk/attachments/20021016/6a2ea9e0/attachment.html>