NYCPHP Meetup

[Jim Hendricks(Biz Computing)]

That's what I'm doing now, but in order to build the whole tree requires 
multiple queries with this design. My latest idea is to add a tierlevel 
field so I won't have to issue a query for parentID = 0 ( top level ) 
then iterate this result & generate a query for parentID = the id of the 
row we are on in top level etc. right on down the line.  If I have 4 top 
level projects each with 3 sub projects and 1 of the subprojects have 2 
subprojects this would require issuing 1 toplevel query, 4 2nd level 
queries,  12 3rd level queries, and 2 4th level queries.  All told for 
this simple tree I will have issued 19 queries.  If I have a tierlevel 
 I can issue 1 query per allowable tier which would be 4 queries in all 
for a max 4 tierdepth tree.  This would be the same no matter how many 
items I have in the tree, nor how many children etc.

janis p gale wrote:

>or, if you were really lazy,
>you could just have a self-referencing table...
>
>tblObjects:
>objectID
>parentID
>fname
>lname
>etc...
>
>where parentID is the objectID of this object's parent
>
>what's nice about this is, you could query just one table
>to find all siblings -- just search for equivalent parentID's.
>similarly, it's easy to find orphans and objects that
>came before all others -- where parentID = NULL.
>
>
>--- Unsubscribe at http://nyphp.org/list ---
>
>
>
>
>
>  
>