Re: Oracle and PICK
Date: Sun, 18 Apr 2004 19:32:07 GMT
"Ross Ferris" <ross_at_stamina.com.au> wrote in message
> "Dan" <guntermannxxx_at_verizon.com> wrote in message
> 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
> > influences to TCO. A good example of why PICK might actually have
> > 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
> > 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
> > be unacceptable to those netizen police out there that find excessively
> > URLs in newsgroups are impolite.
> > Regards,
> > Dan
Received on Sun Apr 18 2004 - 21:32:07 CEST