Re: Oracle and PICK

"Dan" <guntermannxxx_at_verizon.com> wrote in message news:2Zhgc.5856$Aq.1415_at_nwrddc03.gnilink.net...
>
> "Ross Ferris" <ross_at_stamina.com.au> wrote in message
> news:26f6cd63.0404170616.236f30a9_at_posting.google.com...
<snip>
> Hi Ross.
>
> You do make good points, but evolving business requirements and the
> adaptability/flexibility of the system seem to pose as great in not
greater
> influences to TCO. A good example of why PICK might actually have orders
of
> magnitude higher TCO in cases where applications share data or need to
> integrate can be found right in the comp.databases.pick newsgoup under the
> subject line, "Why meaningful Item ID's suck."
>
> Pick is so bound by its physical organization, that changes to logical
> identifiers across a set of conceptually related items leaves it open to
no
> other choice but to entirely redesign an entire system. In the case of
the
> thread mentioned, the work was estimated to take nearly two years. Note
> that Dawn, in her concern for TCO, recommends to the OP, "Best wishes and
> make 'em pay". I'd recommend reading the whole thread to anyone who is
> interested.

That quote didn't sound like me, but I'll believe I wrote that ONLY because it sounded like a (poor) SOLUTION rather than the problem statement was given to the experts. It sounded to me and to others as if there were some very common "design patterns" that would typically be employed to handle the situation at hand and yet the customer picked something that really was not at all a good solution from the information we had. I likely suggested that the consultant on the case advise the customer of the relative costs of various possible solutions and if they still pick a non-sensical and expensive solution, well, then make 'em pay ('cause that was their choice). I sound wicked in your quote here, and I'm a fair bit gentler than that (except when, well, nevermind), so I had to chime in. Cheers! --dawn

<snip> Received on Sun Apr 18 2004 - 01:49:50 CEST