It doesn't feel like you need a tree structure at all. Maybe I am missing something...

If you really do need a tree then Joe Celko probably has what you need. (skip the travelogue at the start)

table: Categories:
    category_desc | catID

table: Items:
    item_desc    | itemID | catID

table: Attributes
    attribute_desc  | AttributID | itemID
    

SELECT     category_desc, item_desc, attribute_desc
FROM      Categories, Items, Attributes
WHERE     Categories.catID = Items.catID AND
    Items.itemID = Attributes.itemID;
[download]

This scheme has many advantages over the "multiple tables" solution. A couple are:

1. You won't have to add a table every time you add a category.


2. With cascading deletes, you don't have delete tables when you delete a category.

This scheme has many advantages over the "one big table" solution. Three are:

1. You won't have to add/delete columns if you add/delete attributes
2. In a normalized table structure you have a lot more flexibility with the queries.


3. if you change a description you will do it in only one place

This scheme has no disadvantages over the two you have been considering. If performance is an issue. (and it is unlikely that it is) You are better off exploring caching of one sort or another.

Apart from being off topic, you might do better by asking database questions on a database forum. The monks are a nice bunch, but not every problem is a nail.

email: mandog