Re: Oracle and PICK

"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message news: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.

I'll agree with you on everything you've said. You mentioned in another post that Pick-like application systems are a very good value for certain kinds of applications, sets of requirements, and environments, and I actually believe that -- especially those that last 15 to 20 years with little major upheaval. But those very same strengths could work against pick-like DBMS's in other circumstances, while RDBMS's might shine. I think we can agree to agree here.

• Dan

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 - 08:13:41 CEST