Re: Natural keys vs Aritficial Keys
Date: Sun, 17 May 2009 04:04:26 GMT
Message-ID: <e1MPl.28402$PH1.27500_at_edtnps82>
Bob Badour wrote:
> paul c wrote: >
>> Tony Toews [MVP] wrote:
>>
>>> paul c <toledobythesea_at_oohay.ac> wrote:
>>>
>>>>> (Occasionally they would have to rebuild a particular item. The
>>>>> gravel pad at one
>>>>> client where these are stored is about a mile square. Well, if
>>>>> the plant has a
>>>>> large expansion, and there's a lot of snow that winter, you can't
>>>>> find the
>>>>> assemblies. Until the expansion is finished a year or two
>>>>> later and you're
>>>>> looking at the excess assemblies which are laying on the gravel..
>>>>> And the folks at
>>>>> the plant getting paid $25 and $30 an hour love being told to go
>>>>> through all the
>>>>> items on this gravel pad looking for particular assemblies. A
>>>>> great way to spend a
>>>>> shift rather than hauling stuff around or whatever.)
>>>>
>>>> i also meant to add that the above shows the beginnings of a case
>>>> study that might be useful in general, although it's not clear
>>>> whether getting rid of the union is a system requirement.
>>>
>>>
>>> Now this was about eight years ago so we didn't have the hand held
>>> devices with
>>> convenient GPSs that are presumably available these days. It was
>>> quite a bit more of
>>> a pain to assemble such a ruggedized device. I did a bit of
>>> research, not a lot,
>>> and couldn't find anything other than external wire attached GPSs.
>>>
>>> Nevertheless it was my suggestion to give the guys a device which had
>>> a hand held
>>> computer of some sort with a bar code reader and a GPS. Every month
>>> or two send them
>>> out scanning each bar code they could find. If they scanned the
>>> same item with the
>>> bar code at each end well who cares. Then come back to the office,
>>> download the data
>>> and now you know exactly where your inventory is. Tony
>>
>> Now you are diverging, imho, magic wands and such 'devices' being the
>> system equivalent of what Edward de Bono might have called porridge
>> words. That stuff can never outlive a useful concept, call it the
>> techno trap if you want., .
> > The fundamental problem Tony had was nobody ever put bin numbers on the > inventory bins. Solving the problem is as simple as adding a logical > identifier, any identifier, to largish areas of the inventory field.
most db experts can't say what the fundamental problem is when faced with multiple systems. I don't like to argue with Bob B because i usually lose the argument, but I don't know what inventory bins have to do with the so-called unit load devices on 'planes. There is so much bureaucratic fooferah to do with those it makes most heads spin, which I could probably prove, having known a few airline employees. One outfit did take inventory of the ULD's themselves, not their contents but their ACP-based system would only allow that enquiry every Thursday at UDT+1 to UDT+1 plus thirty minutes, sorry I don';t know how to type UTC. When you get into big inter-linked systems, nothing is simple, except usually the experts who are paying you. you must abstract the parts to make any sense of the whole. As much of a fan as i am of join as fundamentalk techinique, there is more. most of the people i used to know used join to simulate hierarchies. I don't know if it's still true but most mechanized systems for 'bins' about fifteen years ago mostly ignored bin identifiers, instead using imaginary locations which were mapped from time to time to real locations. This was the only distinct hardware could communicate. One European outfit fell into the trap of assigning a unique db message to every possible event. It was full of holes, eg., totally at a loss to decide what to do if a plane originating in Newark heading for Zurich was re-routed because of a storm. The inherent db solution was to eliminate the muriad messages and replace them with insert, delete or even update to common 'tables'. But of course, that implied a loss of 'jobs for the boys'! Received on Sun May 17 2009 - 06:04:26 CEST