Re: Agility and Data Design (was: Dreaming About Redesigning SQL)

In article <Mv%lb.5734$9E1.26853_at_attbi_s52>, Marshall Spight <mspight_at_dnai.com> writes
>"Mike Preece" <michael_at_preece.net> wrote in message news:1b0b566c.0310231728.4e6
>43b71_at_posting.google.com...
>>
>> As for the number of lines of code - again I'm afraid I can't comment,
>> I've never bothered to count. I suspect though that none of them would
>> have required a million lines of code. Maybe? Dunno. I can say that,
>> given the lifespan of many of those systems, it is not all that
>> unusual for the apps to have been written and maintained by a hundred
>> different developers - over the course of 20 or so years. The majority
>> of businesses running Pick would have had an IT staff of 1 or 2 - if
>> any at all. Some, although not very many, have had a hundred
>> developers working on them at the same time. Some of the Pick systems
>> out there are critically important - I'm talking "matter of life and
>> death" stuff here! Do you really think these systems would be running
>> if data corruption was "a way of life"?
>
>Well, it sounds like what you're describing falls into the category of
>what I was describing as smaller homogeneous systems, where I
>said it "may work well enough." If everything is written in the same
>language, it's a good deal easier to write your integrity enforcement
>code procedurally. (I still think that's a worse technique than
>declarative integrity enforcement, but you may offset the cost by
>gains in other areas.)
>
Except you've left out a third form of integrity enforcement. The one where it's a fundamental characteristic of the design. You don't need the app to enforce it, you don't need the database to enforce it, it "just happens" because "that's the way it works".

To give an example - let's go to our classic example of the invoice. In SQL, when you delete an invoice, you need to go and delete all the related rows in all the tables that make up an invoice. You use cascading deletes to enforce referential integrity. Some other database may require you to write a procedure to go through all relevant bits to delete all references to the invoice. Those are the two scenarios you describe.

But in MV, you have one RECORD per invoice in the INVOICES file, you just do ONE delete, and all the information associated with the invoice is gone. Without the invoice, all the associated data cannot exist because there is nowhere for it to exist *in*.

Oh - and as Mike says, corrupted files aren't common. In some 20 years, I have yet to meet a corrupted MV file. Yes I have met corrupted data, but finger trouble happens to SQL too ...

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
Witches are curious by definition and inquisitive by nature. She moved in. "Let 
me through. I'm a nosey person.", she said, employing both elbows.
Maskerade : (c) 1995 Terry Pratchett