Re: Relational and multivalue databases

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c16cp5$ob6$1_at_news.netins.net...
> Mikito -- I might not have been clear about the theory side on this. Here
> is my dillemma -- I have studied database theory and I have used many
> databases and data storage approaches. It seemed to me that there are
many
> folks who have been taught or who believe that the relational data model
> actually leads to a better solution in data quality, database maintenance
> over time, etc. That is, it seemed from my studies that a company would
be
> the best steward of their financial resources if they were to employ a
> relational database.

I have been on nonrelational database implementation side as well. But nobody on this group could care less what my relational experience is, let alone nonrelational.

> However, my experience tells me that the implementations of the relational
> model "seem to" (I admit I have no concrete proof of this) be more costly,
> without corresponding benefits, to the corporate owner.

Let managers worry about the cost, and, as technical people, let us be fascinated with technology.

> If the relational model is not intended to yield a better solution, when
> taking into consideration all factors, than a non-relational model, then I
> could care less about it -- would you still care about it then?
>
> So, let's look at the big picture of requirements for an application that
> includes data storage -- if we look at the overall cost of ownership
> (including data quality, ongoing support costs etc) of an RDBMS is it
lower
> or higher than the implementations of other models such as PICK. My
> hypothesis is that it is more expensive (often considerably more) to
employ
> an RDBMS. Is this irrelevant? I don't think so -- I think it tosses into
> question what the purpose of the theory is in the first place.
>
> So, what is our goal in having a good theory of how to store and retrieve
> data? --dawn

The purpose of the theory is leading industry to high-tech solutions, rather than surrendering to chaos of ad-hock approaches. Received on Sat Feb 21 2004 - 03:07:45 CET