Re: Oracle and PICK

From: Bill H <>
Date: Tue, 20 Apr 2004 05:21:03 GMT
Message-ID: <3r2hc.172867$K91.437350_at_attbi_s02>


>"Dan" <> wrote in message


> 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 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
> 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.

The record key in a pick-like dbms is the primary key. Always. Sometimes meaningful data is stored there (such as a Vendor's invoice#) because it is unique. Sometimes a simple counter is used and all meaningful data is stored in the record.

Your observation of the referenced c.d.p thread stumbled across an ongoing discussion in the pick-like community - documentation and structure.

Unlike other RDBMS products, pick-like applications control the dbms, not the other way around. I always look at an RDBMS like the students in a religious school: uniforms, clean, sitting up straight, saying "yes sir/mam", doing the work quietly, etc. I see a pick-like dbms as a public high school, where everyone wears different clothes, draws grafitti on the lockers, smokes out back by the auto shop, talks in class, etc. In order to learn, the student _must_ provide the structure to succeed. The same is true in a pick-like environment; the application developer must provide the structure. All the same tools are there, as they are in an RDBMS, but they just aren't required by the database.

Because of this, developers do stupid things, like those discussed in that c.d.p. thread. A pick-like development environment is much different in that the developer is assumed to know something (a lot actually) about the application being written, the toolsets being used, the network topography delivering stuff, and the users doing their jobs.

One may like or dislike this. But it explains a lot.

Bill Received on Tue Apr 20 2004 - 07:21:03 CEST

Original text of this message