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

"Marshall Spight" <mspight_at_dnai.com> wrote in message news:<TELlb.1998$mZ5.16661_at_attbi_s54>...
> "Dawn M. Wolthuis" <dwolt_at_iserv.net> wrote in message news:6db906b2.0310191819.4e374303_at_posting.google.com...
> > ... And that
> > the reason for that is to help control the integrity of the data. I
> > have no doubt that there is some good in doing this, but the cost from
> > my perspective is not worth the benefit. That is not to say that it
> > is not important to protect the data, but that there are other means
> > of doing that. It can be protected with quality assurance (also
> > flawed, of course) on the sum total of all applications that maintain
> > it.
>
> In my experience this approach is uniformly a disaster. Applications
> are *not* the right place to be enforcing integrity; they *cannot*
> do a decent job of it. Integrity has to be enforced centrally and
> declaratively.
>
> Consider a multi-use enterprise database without centralized
> data integrity. Each business rule or integrity constraint
> or bit of semantics that is stored in Java application code is
> unknown and unenforced for every app that ends up being
> written in python or C++.
>
> All the approaches you are suggesting may work well enough
> when there's one or two apps written by perhaps as many as five
> developers. The schema all fits on a nice 8.5x11 sheet of
> paper in a big font. All the integrity constraints may be kept
> in the developers' heads, and maybe you won't run in to too
> much corruption, or perhaps you can recover from it "agilely."
> But in a situation with 30 apps in five different languages
> totalling a million lines of code, written by a hundred
> different developers, if you do not have central integrity
> constraints, data corruption will be a way of life.
>
>
> Marshall

I think it might be interesting to compare and contrast our different experiences.

You say:
> In my experience this approach is uniformly a disaster. Applications
> are *not* the right place to be enforcing integrity; they *cannot*
> do a decent job of it. Integrity has to be enforced centrally and
> declaratively.
>

Correct me if I have this wrong:
What you're advocating instead is a function of the DBMS. It isn't a function of the Pick DBMS. In your experience doing things any way other than through a function of the DBMS (as a business rules function as part of the application code for example) would uniformly lead to disaster?

Hmmm...

During the last 22 years I've worked on a lot of Pick systems. Some of them were pretty big. Certainly running 30 apps is not uncommon. In my experience, all of them were written in PickBasic (or one of it's variants depending on the "flavour" of Pick) - not "five different languages". I can't comment on systems written in Java for instance - and I take your point about the difficulties inherent in having business rules modules in several different languages.

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

Regards
Mike. Received on Fri Oct 24 2003 - 03:28:09 CEST