Re: One Ring to Bind Them

In message <nnIDc.125667$Sw.113988_at_attbi_s51>, Marshall Spight <mspight_at_dnai.com> writes
>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?

You mean a bit like you can't delete a company if there are any outstanding invoices? No that can't (or rather, shouldn't) be done natively and declaratively in MV. But I wouldn't call that a "container and contents".
>
>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?

Let's give an example - an owner can have multiple cars, and a car can have multiple owners.

What I'd do is have an OWNERS field in the CARS file, and declare it as an index. So if I want to know who owns a car, I just list the car and pull the owners into the listing. If I want to know what cars someone owns, I list all cars owned by that person.

Actually, thinking about it, this seems like a perfect case of "ON DELETE RESTRICT" - don't delete an owner if any cars only have that owner. But MV would leave that to the app (I'd rather be able to enforce it, but it doesn't seem to be a problem in real life ... :-)
>
>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.

And centrally enforced constraints are a lack in the MV model ... but design-enforced relations are its strength. Because it doesn't need 90% of relational constraints that are necessary in relational, it hasn't bothered with the other constraints (which I agree is a pity).
>
>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?

Are they even *RELEVANT*? Take any theory in PURE mathematics. It's complete, it's correct, it's self-consistent. And if it assumes that parallel lines in three dimensions can meet, it doesn't break. It just models a completely different world to the one we actually live in ...
>
>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.
>

I think I'd agree here ... MV is great at ease of use. It's great at enforcing entity-level integrity (can't have an adjective (or adjectival clause) without a noun for it to describe). It's not great at enforcing constraints *between* *entities*. But then, neither is the real world :-)

Relational fits theory fine. MV fits the real world fine.
>
>Marshall
>

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999