Re: deductive databases
Date: Sat, 14 May 2005 20:38:08 -0400
Message-Id: <qbiil2-164.ln1_at_pluto.downsfam.net>
mountain man wrote:
> "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.
Two objections from experience.
First, if you set the depth at N, somebody will need N+1. They will need it on Christmas Eve coinciding with your daughter's wedding.
>
> 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.
See first objection above.
>
>
>> 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 work-
> arounds to this type of problem without involving
> any form of esoteric generalised recursion theory.
>
Agreed, you don't need anything esoteric, the solutions are well-known, it's just they all contain the moral equivalent of a divide by zero.
>
>
>>> 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.
Is it possible they are not hitting the system that hard? Not a high volume of transactions? Sounds like for lawyers it would be no problem to explode a hierarchy on each change, since they just don't change that often, no?
>
> If you relied upon theory you'd have a problem.
> Fortunately there are viable practice-based
> alternatives in SQL.
???
-- Kenneth Downs Secure Data Software, Inc. (Ken)nneth_at_(Sec)ure(Dat)a(.com)Received on Sun May 15 2005 - 02:38:08 CEST