in reply to Pulling back paths from a database to populate form field

You are making it harder by having the parent-child relationships in a text field. You have to read and parse the text field in order to figure out whom the parent or child is.

I suggest you try this as your table,

Table: Categories id (primary key) parent_id (foreign key on the id column, set to NULL for the upper-mo +st node) name text

This simple structure will allow you to go infinite levels deep without an abitrary limits like your current tables (due to the size of your text columns).

As for the coding, you just need one recursive routine, to build your tree.

my $dbh = DBI::connect(@connect_values_here); get_categories_at( undef ); sub get_categories_at { my $parent_id = shift; my @values; my $sql = "SELECT * FROM TABLE WHERE "; if (not defined $parent_id) { $sql .= "parent_id IS NULL"; } else { $sql .= "parent_id = ?"; push @values, $parent_id; } my $hash_ref = $dbh->selectall_hashref( $sql, 'id', {}, @values); for my $id (keys %{$hash_ref}) { print "ID => $id\n"; get_categories_at( $hash_ref->{$id}{parent_id} ); } }

This has some short-comings, mainly I did not test it for one, and it does not print the categories in a particular order (though that can easily be fixed). This should be a good enough starting point to test your own model though.

Good Luck

Replies are listed 'Best First'.
Re^2: Pulling back paths from a database to populate form field
by osunderdog (Deacon) on Apr 01, 2007 at 07:47 UTC

    I concure with the prescribed approach. Some databases, Oracle in particular, support this self referential table with an SQL syntax "CONNECT BY". You might check your favorite MySQL forum to see if there's corresponding idiom.

    A similar problem is mentioned here: database table advice Update: I guess it's related because it's from the same author!

    This problem shows up a lot in Bill-of-materials type applications.

    Hazah! I'm Employed!