Re: Oracle and PICK

From: Dan <guntermannxxx_at_verizon.com>
Date: Sun, 18 Apr 2004 19:32:07 GMT
Message-ID: <XIAgc.8087$Aq.5905_at_nwrddc03.gnilink.net>


"Ross Ferris" <ross_at_stamina.com.au> wrote in message news:26f6cd63.0404180416.44296c62_at_posting.google.com...
> "Dan" <guntermannxxx_at_verizon.com> wrote in message
news:<2Zhgc.5856$Aq.1415_at_nwrddc03.gnilink.net>...
>
> Hi Dan !
>
> I've read the thread, though my conclusions are somewhat different -
> I'd suggest the topic should perhaps be "Bad database design sucks -
> with ANY DBMS !"
>
I can see where these conclusions are born out of the discussion.

But the thread started with a real-world problem driven by the fact that the company had merged with another company. It therefore had to incorporate and map a new set of logical identifiers, over history. The problem wasn't necessarily the mapping between logical identifiers themselves, but with the deletorious effects it would have on each and every application, report, etc. that relied on the original internal data model. An RDBMS solution was proposed (see first response to the poster) that, IMO, would have overcome this problem easily.

> I also note that the application itself appears to be quite ancient,
> so the methodologies that were used at that time were probably
> sub-optimal by ANY standard :-)
>
Granted, and perhaps that is a sufficient reason that would pose problems for a relational dbms as well. To me, the overriding problem in the conceptual problem space seemed to be a problem that is relatively common in the real world was posing great difficulties for PICK. But perhaps you are right and it has nothing to do with the fact that any data access path or index path is hard-coded into tightly bound applications.

> Actually, given the age of the application, this could be a classic
> TCO study, if we could find an "Oracle" (or other relational) solution
> somewhere from the same vintage to do a direct cost comparison.
>
I agree wholeheartedly. Dawn asked for recommendations in the past to determine a set of criteria for a head-to-head test. This particular type of scenario is exactly what I had in mind, if it is indeed possible to come up with an objective comparison.

> Do you want to pose the question to CDP Dan ? Are there enough
> "Oracle" people here to get a corresponding reference point, or would
> the request need to go directly to that group as well ?
>
> Given we are talking historical figures from 15-20 years ago, I would
> think that the client companies may not mind "anonamously" making real
> (or close approximation) figures available ....

I'm not so sure this would work.

> get some quantifiable facts & figures on where TCO figures do stand
> over the long term !

Yes. This seems like an excellent opportunity if someone was really willing to dedicate themselves to the research, or was going to be paid for it. However, it is a lot of work and I doubt if anyone really has the time and inclination to do this on a volunteer basis. It would also be interesting to find out how many companies, owners, or users felt that using either an MV system or a relational system contributed to a stifling of business innovation or process by virtue of the rigidity of their core information systems. We could call it the innovation/competitiveness impedence cost. It is a phenomena I've seen with local IMS systems here.
>
> >
> > 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.
> >
> > This makes as good ancedoctal evidence anything else.
> >
> > I'm refraining from posting a URL to the referenced thread because it
might
> > be unacceptable to those netizen police out there that find excessively
long
> > URLs in newsgroups are impolite.
> >
> > Regards,
> >
> > Dan
Received on Sun Apr 18 2004 - 21:32:07 CEST

Original text of this message