>The only time I've done something like this there was a requirement to allow a 'bundle' to be made up not only of items but also to contain other 'bundles'. The data structure was something like (using your Items table as is):
>
>Bundles
>Id (PK)
>Name
>Price ?
>etc....
>
>BundleList
>Id (PK)
>BundleId -> Bundles.Id
>Quan
>ComponentId
>IsBundle
>
>If IsBundle is false then ComponentId points to Items.Id
>If IsBundle is true then ComponentId points to Bundles.Id and can be processed recursively to also expand that bundle if required. End result is that even deeply nested collections of bundles can be unwound to a full list of items.....

Last time I had something like this it was a similar table (self-referencing) in a production environment. The term used was "poluproizvod" (semi-product), which was appropriate in that context. It was to be used as a component in a final product, and it could have contained semi-products. It didn't go deeper than two or three levels. Don't know whether this expression would work in English. Sub-assembly, maybe.

Actually, then I heard from someone, in a discussion on the subject, that the most complicated and largest contraption in use, an ocean liner, didn't go deeper than ten levels.