Bhavbhuti, for accounts you don't need a separate hierarchical method as the number itself has the hierarchy. If you add another hierachical layer then you are complicating the problem.
In fact sometimes it can be a pain when the accounting tree grows, as each level is capable of only 10 sublevels. If you don't plan well it can limit you (I have about 15 years in accounting experience); you can rewrite the tree, but it breaks backward compatibility (something many accountants don't care about because they break the books every year).

>Hi Javier
>
>>Bhavbhuti, I made the family approach several years ago and had no problem, and I found that I did not have to write complicated code to maintain this approach. This is why I have kept it. The problem with hierarchies is old and has generated a lot of literature. If I remember well, I think Joe Celko (one of the best experts in SQL) has written about solving hierarchies.
>
>Trees in SQL I have studied the article and since then I have had the guts to go for the hierarchial data for Accounts and Items master tables.