programming unlimited "categories" in python ?

[Steve Holden]

"Terry Reedy" <tjreedy at home.com> wrote in message
news:46gB7.151079$5A3.52079649 at news1.rdc2.pa.home.com...
>
> "Stephen" <shriek at gmx.co.uk> wrote in message
> news:97ae44ee.0110230529.5c33dd83 at posting.google.com...
> > > > I'm developing a catalog application (storing its data in a
> > > > relational database), where catalog entries are categorized
> > > > by one or more categories/subcategories.
>
> From the above and your example catagories, I mistakenly assumed that
> you wanted to store relational data in your relational database, and
> described how to do that.  Instead, it seems, you want to simulate a
> dynamically adjustable hierarchical database using an RDBM as the data
> manager behind the scenes.
>
> > > >  It would be nice to have "unlimited" levels of subcategories
> ...
> > Thank you for the advice, Terry.  Sorry if I'm being obstinate,
> > but I think the problem is a little less simplistic than it first
> > appears.
>
> Definitely (and wanting a solution to your actual problem, now better
> explaned, is not really being obstinate).
>
> > Let's look at the everyday addressbook in Act! or Outlook ?
>
> I'm not familiar with either, or any similar programs.  My closest
> point of reference is the Windows registry.  Otherwise, my experience
> is 'limited' to static schema (from users viewpoint) relational
> databases.
>
> > How would you create unlimited levels of categorisation
> > and unlimited numbers of subcategories ?
>
> Interesting question.  To say much more, I'd need more specification.
> Such as, do you want to do search and selection with the RDBM (mostly
> off the disk) or with Python (possibly in memory)?  If with the RDBM,
> I think my original comment stands:  if you want to efficiently (and
> scalably) search and retrieve on any level of the hierachy, then you
> mush explicitly store each level with each item.  An alternative would
> be an expandable tree index structure written, in this case, in
> Python.
>
This is a classic SQL problem, which most often manifests itself in
bill-of-materials processing in which parts are components of other parts,
and so on down to many levels. One reference to solutions can be found
towards the end of

     http://www.dbmsmag.com/9603d06.html

It's one of those problems that has an "obvious" solution, which is very
non-obvious until you see it.

regards
 Steve
--
http://www.holdenweb.com/