Re: Newbie DBase architecture questions

From: Mikito Harakiri <mikharakiri_at_yahoo.com>
Date: 30 May 2002 16:41:33 -0700
Message-ID: <bdf69bdf.0205301541.7957a14c_at_posting.google.com>


Hierarchy wouldn't cut it. Products so often belong to more than one category that merchants have it in 2 and more departments. General DAG and Materialized Transitive Closure solves the problem. Navigating Transitive Closure is not complicated, and isn't necessarily slow, if you are aware of database performance tuning.

"Tobin Harris" <comedyharris_at_hotmail.com> wrote in message news:<ac1hdn$m7s8f$1_at_ID-135366.news.dfncis.de>...
> Hi there,
>
> I've been around this type of problem for a while, but not got a solid fix
> on it yet.
>
> My first thoughts are that you should separate the products from the
> hierarchy. Where a product (lava lamp etc) sits in the online catalogue
> isn't really much to do with the product, but rather where us humans want it
> to appear. Therefore you could look to create a table(s) to represent
> hierarchy, and then 'pin' products into various points in this hierarchy.
>
> Then comes creating the tables to represent the hierarchy, which is the
> difficult bit. I think Joe Celko has given some recommendations for this
> sort of thing in one of his books.
>
> From a relational point of view I suppose you're lookng at a m:m
> self-referential relationship (that can't be the correct term!?). I've
> avoided using these in practice, since you have to resort to things like
> tree-walking and such, which is complex and slow IMHO.
>
> If you can't make headway with this, then you may look at a fixed hierarchy,
> where you have a maximum of n levels deep. From a human perspective this may
> not be a bad thing, but to me it doesn't *feel* right.
>
> Sorry I couldn't be of much help here, but it will be interesting to hear
> what others say!
>
Received on Fri May 31 2002 - 01:41:33 CEST

Original text of this message