Re: One Ring to Bind Them

Marshall:

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:GipDc.159689$3x.28156_at_attbi_s54...

>

I'm not sure why it is so difficult to express this concept. An MV environment is both a data store and an application server. It is _NOT_ an RD model. To discuss its attributes strictly from a datastore perspective is neither fair nor accurate. To understand its methodologies for directly solving business problems requires the willingness to work with its two functions: storage and application properties/methods/rules/etc.

Secondly, solving business problems requires a great deal of flexibility. A non-relational model can, in a number of instances, provide additional flexibility over and above whan the RD model can. Not because the RD model is incapable, but because the RD model declares for itself particular limitations and methods of operation. This structure doesn't always work ideally. Do I understand RD proponents to declare that it does in all circumstances?

This is fine. Why is it we can't allow that our own prejudices create limitations on the ability to formalize solutions? It takes Godel's Incompleteness Theorem to declare that some certainties have gotten too big for their britches. It can happen to anybody. :-)

For years HP calculators used RPN (reverse polish notation) instead of standard algebraic entry mode (AEM). Nowadays they offer both. Does this mean RPN is worthless or worse than AEM? No. Many people prefer RPN. Is AEM more often used? Of course, but that doesn't say anything about RPN or those who prefer to use it. The same can be said about the RD model. Not everyone prefers it.

> Yes, it understands the meaning of this, so it knows what
> a one-to-many relationship means. Does it have any other
> facilities for understanding meaning? It can do
> ON DELETE CASCADE but can it do ON DELETE
> RESTRICT? Can it handle and understand many-to-many
> relationships? Can it understand and enforce arbitrary
> constraints a la SQL's CHECK? (These are actual questions,
> not rhetorical ones; I'm not that familiar with MV.)

Of course it does, and can. Remember it is both a datastore and an application environment wrapped into one. So, whatever needs to be done can be done. It is simply that this additional functionality is stored in the datastore too. Most of the MV products can even understand and cope with SQL functionality.

Like I said before, this is not to say that the MV model does everything...as nothing can. But it provides an interesting confluence of tools and capabilities that render the model very useful in solving business problems for many people and businesses.

Bill Received on Sun Jun 27 2004 - 23:43:04 CEST