Re: Oracle and PICK

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c5sfri$8mq$1_at_news.netins.net...
> "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).

Yes, and the same thing can happen with poor design methodology in any type of system, including relational.

> 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
>
Dawn,

The quote was out of context, but it highlighted a point I wanted to make. Since the system couldn't adapt to changes in terms of logical and physical independence, people began blaming the owners, requirements, and designers of the system.

I wasn't trying to make you sound wicked, and out of context, that is probably how it comes off. That is why I recommend that the entire thread be reviewed, in context, in order to be fair to everyone.

Warm regards,

• Dan

> <snip>
>
>
Received on Sun Apr 18 2004 - 01:58:53 CEST