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

"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 Received on Thu Oct 23 2003 - 09:43:47 CEST