Re: One Ring to Bind Them

"Bill H" <wphaskett_at_THISISMUNGEDatt.net> wrote in message news:jY2Gc.24273$%_6.8192_at_attbi_s01...
> >
> > 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."
>
> An MV relationship isn't an RM relationship; at least it isn't stored as
> such. It is an expression of a relationship, the containment of which
> resides in the database. e.g. a relationship exists between a vendor and
> invoices, between a check and invoices, between a bank transaction and a
> check, and between a reconciliation and checks.
>
> So, your statement that the only relationship an MV dbms can understand is
> containment is not true; though not exactly false either because it does
> fundamentally understand that. The MV model understands defined
> relationships, which are stored (or contained) within the database. These
> defined relationships are then understood by the MV model.
>
> I can set a relationship between a vendor and invoices by simply storing the
> data required for the relationship then defining the relationship. So, I
> can say:
>
> :select vendors invoices
> :sort invoices with no pddate by pddate
>
> I can then define the above as a stored procedure named
> "List-Unpaid-Invoices", then execute:
>
> :List-Unpaid-Invoices '12345' which will list all unpaid invoices for vend#
> '12345'.
>
> Now, was this only containment? I think it was much more than that.
> However, it is what it is and the RM model will do the same thing; just
> differently.

So I read all of your comments, and I couldn't figure out what they meant. I didn't see any clear answer to whether MV supports relationships besides containment. In fact you evaluated that stament as "not true but not exactly false." I have no idea what that means.

> Notice that the relationship and the relationship data has to
> be stored somewhere in both models.

Of course.

> One of the interesting aspects of the
> MV model is the data and relationship is stored in the database.

Uh, same with RM.

> > 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.
>
> The models we use create "stupid" tricks. It's the models that create the
> constraints to make some tricks stupid and others smart. An RM "stupid"
> trick may be an MV smart move; and visa-versa. However, most design and
> development are constrained by the base delivery model: server vs
> client/server.

I disagree. There are specific well-documented and *fundamental* disadvantages to managing integrity in applications instead of centrally. This is independent of MV vs. RM vs. whatever.

> > 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.
>
> Let's reconcile a bank account. We need a primary account table and a
> transaction table in both models. However, in the MV model we don't need
> anything more than this. We will define the keys of the transactions to
> include the account#, so the account table can (and probably will) contain
> the ref# of the transactions. The transaction key would look like:
> Account# and transaction#.

You're going to reuse transaction numbers in different accounts? And you're also going to include the transaction number in the account table? That kind of redundancy leads directly to data corruption.

> Now, what good is this? As Mr Youngman points out it only takes one disk
> read to get the account and its relationships to the uncleared transactions.
> This is an almost instantaneous response to our web clients. So there's an
> upside.

Ugh. Let's please not talk about disk reads.

> > 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.
>
> I sit in a corporate VP meeting and discuss this with them and they with me.
> We all see the same thing. I'm not the odd man out here. In addition, I
> can almost directly translate their vast knowledger to the dbms design and
> relationship definition. I think this is good!

How is this a response to what I wrote? It sounds like what you are saying is "I work in the computer industry."

> > > 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.
>
> They really do. They do primarily the same things. We're not talking
> nuclear reactors and cigarettes. :-)

Okay, how do you map a relational table like this into MV:

create table Tri
(

 a int,
 b int,
 c int,
 unique(a,b),

> > > > 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.
>
> Yes and no.

This kind of answer is hard to work with. It's much easier to understand you when you give me a straight answer. Saying "yes and no" is worse than not responding, because it adds confusion.

> You can always hand write code in an applicaton. You can also
> store the code in the dbms as triggers, constraints, relations, etc. The
> difference is that the RD model does some things one way and the MV model
> does some things the other way.

Remember when I asked you to "be specific?"

> The MV model is much more
> application-centric. This is only bad when working with the RD model, where
> this is defined as bad (or "stupid"). Most things are done the same though.

No, it's bad for more fundamental reasons. If you don't enforce constraints centrally, then integrity support becomes ad-hoc and application-dependent, so one application might fail to enforce a constraint. A constraint that isn't enforced centrally is a constraint that won't necessarily hold.

> > 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?
>
> Let me point out that the MV model communicates with the database, with
> respect to data maintenance, via an application language. Where a RD model
> might say:
>
> INSERT ...
>
> the MV model would need to:
>
> OPEN My file
> READ and Lock New record (make sure noone else is)
> or
> READ and Lock Item to change (make sure noone else is)
> CHANGE data
> WRITE data TO My file
>
> Lock contention is a part of the dbms. There is no such thing as
> "optimistic" locking (unless one is an idiot). :-) But this is an MV
> perspective, not an RD perspective.

Is this supposed to be a response to my earlier paragraph? Because I don't see the answer to my question about "can MV do ON DELETE RESTRICT" anywhere. Can it? What relevance does lock contention have to my question?

> > 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?
>
> Remember, a constraint is defined and stored somewhere. The only value with
> storing outside the application is if some other application is using it.
> This is not a usual requirement but an MV model can simply enforce this via
> via a trigger. We're much more inclined to place this in the application
> because all MV application are server-centric and run in the dbms.

So, is that a "yes?" Are you saying it *is* possible to enforce a constraint centrally?

> > > 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.)
>
> Rule one in life: never say never. Rule two in life: never say I can do
> everything. :-)

It sounds like you don't understand Turing completeness. Also note that I didn't say "everything." I said "anything that can be computed." And I stand by my statement that BASIC can compute anything that can be computed; it is a Turing complete language. This is not the same thing as saying that it is a good language, though.

I appreciate you're trying to help me understand, but I'm having trouble following your posts. It seems like you quote me, then respond, but the response, while interesting isn't a response per se but you talking about something else. I get lost.

Marshall Received on Mon Jul 05 2004 - 20:05:23 CEST