Re: One Ring to Bind Them

"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message news:IbHDc.119764$HG.109138_at_attbi_s53...
> "Marshall Spight" <mspight_at_dnai.com> wrote in message
> news:GipDc.159689$3x.28156_at_attbi_s54...
> >
> > Perhaps I misunderstand, but MV has only the one kind of
> > relationship it is capable of understanding: containment.
>
> 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.

I read that paragraph a bunch of times, but it didn't seem to address my statement that MV has only one kind of relationship it is capable of understanding. Does it have relationships besides containment that it can understand? An example of a non-containment relationship would be cool, if the example does not require hand-written application code to work.

I think the MV and the RM world divide things up very differently. I will note first that "storage" is not a first-tier property of RM, but it is a useful, second tier function that most products support and that most applications take advantage of. It is perfectly reasonable, and useful, to have an RDBMS that does not persist its relations. We could still call this an RDBMS, but we couldn't call it a "datastore."

Another example is managing data integrity in procedural application code. In RM this is considered a "stupid database trick" to quote from another thread. There are significant disadvantages to application-managed integrity rules, to the point where I do not consider it an approach worth discussing (and yes, I've used that approach in the real world.) However, it may be that this approach has lower overhead in situations where you have small development teams and single-application databases.

> 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.

Please be specific. I am very interested in specific examples of specific operations or structures that you feel are hard to solve with RM or SQL and easy to solve with MV. I do believe there are some, but I want to know what they are better. As it stands I have a hard time evaluating the claims of the MV people, even the smart/nice ones such as you and Dawn. I'm not saying I believe, and I'm not saying I disbelieve. I just want to hear more specifics.

> 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?

I don't know how to measure the idealness of a solution, so I have no particular claims about whether the RM is ideal or not.

> 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.

The problem with this analogy is that there is a simple one-to-one mapping between AEM and RPN. It is easy to show that the two methods are equivalent. I do not believe the RM and MV have such a mapping, nor do they support the same operations nor structures.

> > 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.

If by this you mean that you can implement these features by hand-writing application code, then I don't consider that any achievement. I can say the same thing about some Java code and a hashtable, but it's not a good solution.

For example, in another thread someone said (over and over if I remember correctly :-) that if you delete an invoice, all the line items go with it, automatically. Okay, this is the same thing as ON DELETE CASCADE. But sometimes you want ON DELETE RESTRICT. (In other words, if you want to delete a container but it is still containing something, you have to dispose of the contained things first; you can't just throw them away.) Can you do this declaratively in MV? How is it done?

Can it handle many-to-many? I've heard some people say it can, but is integrity enforced automatically, or is it just done with references that are application managed?

Can it *automatically* enforce declared integrity constraints? Can you have an integer attribute and declare that it must always be divisible by 4? Is that enforced by auditing your application code and manually inserting a check at each place the attribute is updated, or is it enforced by declaring the constraint centrally? Does the constraint have a hole in it if you add a new place the attribute can change and forget to put the %4 check in?

> Like I said before, this is not to say that the MV model does
> everything...as nothing can.

I don't think I agree. For example, Java, C++, and BASIC are all able to compute anything that can be computed. They do everything that can be done; no programming language of the future can ever do anything more. (Which is not the same thing as saying there is no room for improvement: FORTRAN < C < C++ < Java < {OCaml, Haskell}, IMHO. But these are usability and expressivity issues, not computability issues; we need to be clear on the distinction.)

> 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.

This is not so much what is under discussion in this newsgroup. I will readily acknowledge that many people use MV to do useful work, and that they solve business problems, and that they enjoy themselves doing so. They on-topic question is the theoretical basis for the tools. Are they complete? Are they correct? Are they self-consistent?

SQL is relationally complete, over its lame type system. It could really use a better type system. This will make it more usable but it won't make it any more complete. SQL is already really good at automatically enforcing integrity; it's a real strong point. OTOH, it's not so good at ease-of-use, and could really stand to improve. I suspect MV is much better at ease of use and worse at enforcing integrity. Understanding why and where one is better and one is worse will help us better use our own systems, evaluate others, and also to build the next generation. In this respect, I think Dawn and I are engaged in exactly the same exploration, although we come at it from different backgrounds.

Marshall Received on Mon Jun 28 2004 - 01:03:47 CEST