Re: Oracle and PICK

From: Dan <>
Date: Sat, 24 Apr 2004 20:44:26 GMT
Message-ID: <KkAic.33330$>

"Anthony W. Youngman" <> wrote in message
> In message <2Zhgc.5856$>, Dan
> <> writes
> >You do make good points, but evolving business requirements and the
> >adaptability/flexibility of the system seem to pose as great in not
> >influences to TCO. A good example of why PICK might actually have orders
> >magnitude higher TCO in cases where applications share data or need to
> >integrate can be found right in the comp.databases.pick newsgoup under
> >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
> >other choice but to entirely redesign an entire system. In the case of
> >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.
> But, as is pointed out, this whole thing comes down to poor design.

This is what I call jumping to conclusions. The design sufficed for over 15 years.
> >
> >This makes as good ancedoctal evidence anything else.
> And, as is pointed out, this SAME MISTAKE is extremely common in SAP -
> which is a relational system.
SAP uses underlying SQL databases, but never in a relational sense. In fact, most ERP systems basically nullify the total benefits of relational databases, partially because of the various DBMS vendors inability to keep propietary physical properties of a data model separate from the logical aspects, and partly because ERP systems have to generalize to an extent that accomodate most primary specializations of a business, but never all of them. Thus, many datamanagement functions are hand-coded rather than enforced by a database. I imagine direct ad-hoc access is absolutely *verboten." It would be even more exacerbated with PICK, but the comparison is merely a matter of relativity.

Unfortunately, PICK supporters argue for arguments sake here in this group. Most support is in the form of "I heard a story that.." or "I believe that so and so", or "I have this opinion, so it must be true", or "I'm a scientist, so I'll bring up topics that have no relevance to data management or database theory." If you believe you have a case, then either develop and publish a case study, or offer to compete a PICK product against the TCP benchmarks, which are very well known, and though not perfectly objective, serve the best place for you to prove your case in terms of competitiveness against current relational implementations.

> Poor design ALWAYS bites you. Pick is no better or worse than
> relational.

Perhaps that is the case if I were conviced that this particular instance was a case of poor design, but I'm not. One of the benefits of the relational theory is that it provides a basis and outline for good design (e.g. normalization). I have yet to see an analog with the same rigorous foundations with PICK. Perhaps you could point them out. And if you want to argue that normalization is harmful, then I would love to see a peer reviewed article in ACM's SIGMOD telling everyone why they are loony for having been convinced of its benefits for all these years. I'm sure a formal argument and proof should be a trivial task for one of your scientific stature.

Because there is a natural tendency for businesses to change, driving natural growth and change in the universe of discourse, leading to growth and change in data structures, one should not then call a system bad design because it has no consistent mechanism to isolate users from underlying physical structure. None of us know what the future will hold except that it brings changes. Relational offers some degree of immunity from this as a model, PICK does not, except for where hacks were built upon the implementation over the years, such as the dictionary, to give it some isolation. By hack, I mean that it was not part of a comprehensive framework for a database and there is little evidence that any PICK implementation will serve the purpose in a consistent and predictable way.

Let's get back to interesting aspects of database theory here, OK?


> Cheers,
> Wol
> --
> Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
> HEX wondered how much he should tell the Wizards. He felt it would not be
> good idea to burden them with too much input. Hex always thought of his
> as Lies-to-People.
> The Science of Discworld : (c) Terry Pratchett 1999
Received on Sat Apr 24 2004 - 22:44:26 CEST

Original text of this message