Re: deductive databases

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:tuuel2-uph.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>> "Alfredo Novoa" <alfredo_novoa_at_hotmail.com> wrote in message
>> news:87t881l00onh3tibjbqvokll34kn2d67s9_at_4ax.com...
>>
>>> To say that recursion is not useful to solve part explosion problems
>>> shows profound ignorance.
>>
>>
>> 1) WTF is this critical inventory explosion problem?
>
> A widget is made of components. Each component is made of other
> components,
> and so on and so on. The nesting level is not defined ahead of time and
> can go to arbitrary depths.

Thanks for the brief.

Yes, arbitary but not infinite depths, and once the maximum depth is chartered, the current entire instance of the problem can be flattened - no big deal. Auto-regen flat structure as required.

Throw the max depth code into an automated exception alert to present on a queue to some workgroup that an instance has arisen where widget_id 123456789 has exceeded max depth.

> Building a flat list of a complete parts explosion for an item therefore
> is
> a hassle.

If you dont know the depth it is, but you build a tool to determine the maximim depth first.

In fact there are literally hundreds of alternative workarounds  to this type of problem without involving any form of esoteric generalised recursion theory.

>> 2) How many organisations are experiencing this problem?
>>
>
> All manufacturers in the world?

Not the ones I've ever had anything to do with.

My main clients have been patent and trade mark attorneys and their IP management systems invariably generate these types of problems where relationships involve trees and their branches. EG:

Tracking the relationships between patent applications, especially divisional patents, that can have parents, which themselves are a divisional patent of another divisional, etc. sounds like the same form of problem.

If you relied upon theory you'd have a problem. Fortunately there are viable practice-based alternatives in SQL.

Pete Brown
Falls Creek
Oz
www.mountainman.com.au Received on Sat May 14 2005 - 05:59:23 CEST