Dragan and Hilmar, below my reply to all of yours ...


>>>Basically I agree with both you and Peter: two tables - items and composition, where composition has two foreign keys: one to parent record in items (to "the item whose recipy this is") and the other to the item table as a lookup (this ingredient is this item). Any ingredient in itself could be a simple item or another composite - but in any case I had there were never more than 3-4 levels. I've heard that even the big ocean ships don't have more than 6-7 levels in their assembly list.

Right; it is very hard to get further, though at first glance one wouldn't guess that.


>>
>>Yes; the two-table structure (articles, composition) allows virtually any number of levels, but for practical purposes, for the end-user, the number of levels should be limited.

I wouldn't know what practicle purposes are; to avoid a treeview becoming to wide (or so) ? so withold the user from reality ? no please. But again, the depth won't be more than 6 or so.

>
>I put a limit after testing - I once manually created an endlessly repeating composition, and tried to display it. On my machine (which had only 4 megs at the time) it broke when attempting to display the 6th level; on better machines it would go as far as 8 to 10. So I put a limit at 5.

I can't guess what this has to do with memory at all. However, you could be dealing with the maximum stack depth. So, normal recursive routines call themselves, and for VFP you'd be dealing with the normal stack (already increased by an IF, a Loop etc) and the program-DO stack (also increasing the normal stack). But note that any recursive structure can be broken down to be in the one program (using arrays ... and yes, consuming memory then).

>
>>>Now the weirdest thing of all: I once spoke with a guy who had a theory that the accounting can be done this way... we were not completely sober, but he was making a lot of sense.
>>
>>I tried something in this sense, a while ago. Actually, it was a single table, because each account only has a single "parent" (the second table is required to resolve the many-to-many relationships: article "parent" can contain many "childs", and article "child" can be contained in many "parents").
>>
>>I also showed the accounts in a treeview. However, the whole project was eventually aborted, and I couldn't test it in practice. I'm no accounting expert, so I'm not very sure about the merits or not of this approach.
>
>Depending on the accounting system, this can work or not. In Yugoslavia there's a double-balance system with a tree-like "account frame" (as they call it now, previously it was "account plan"), where any item would be credited or debited to one account, and a counteritem to another account on the opposite side, so the whole set of items would always have to be in perfect balance. The account plan was divided into ten classes (as per first digit of each account, or let's call that single-digit accounts), then each was split into 3-digit accounts, and the structure so far was prescribed by the law. Beyond that, any chief accountant could invent sub-accounts with up to 8 digits. So, basically, this already had a tree structure and could be used as such, and could even be done recursively.

We just have this, exactly like this (btw in Holland this 0-9 system is very often used). But note that this (0-9) has few to do with the functional application in general;

Just (and indeed) look at the general ledger as a same bunch of "Items" as for products, and look at it from the point of view of calculating the Item's cost price from the (raw) materials used in the recipies. With the ledger it's just the same; just create a "recipe" for an account and have some accounts in there, and if you want to do it again at the lower level, just do it. One rule : one is allowed to book only at the lowest level accounts. So all the "parent" accounts are just summarizations of the bookings of the lower level(s !!).
This system is flexible / dynamical with respect to which parent has which childs, IOW, the whole structure can be changed at any time. In the end this is super-powerful to the accounting department.
The depth is endless, though limited by the stackdepth again (one will never reach that).

Hilmar, where you speak of "rational" with respect to what we all invent, I'd rahtber call this "logic", or better : just the only one way things should be normalized in this world.

BTW, in our app we have another bunch of (?) 30 entities acting this way, because there are many more applications for this (recursive counting / registring / etc); once you have the experience an the examples, you create another full operational entity like this in not more than a few hours.