Re: Oracle and PICK
Date: Tue, 20 Apr 2004 05:21:03 GMT
Message-ID: <3r2hc.172867$K91.437350_at_attbi_s02>
Dan:
>"Dan" <guntermannxxx_at_verizon.com> wrote in message
[snipped]
> 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.
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