Re: Dreaming About Redesigning SQL

Originally posted by Dawn M. Wolthuis

> topmind_at_technologist.com (Topmind) wrote in message
> news:<4e705869.0310191137.57cbf1c7_at_posting.google.com>...

> ...

> 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.

>

Great! So the data integrity is to be as good as the worst application that maintains it. Can you not see that the DATA is the really important commodity here? The applications are really just pretty user interfaces, and they should not be entrusted with full responsibility for data integrity. Especially when there are to be SEVERAL applications... Every time a new application is added that seeks to maintain (some of) the data, your QA team has to ensure that it encapsulates each and every data integrity rule for the data it touches. Ditto when the functionality of any of these applications is extended.

What you advocate is what we had no choice but to do years ago, before database-level constraints existed. You built a screen to enable input of orders, you had to encode ALL the data integrity rules in the screen code; you added a second screen to facilitate bulk-input of many orders, you had to duplicate all the data integrity rules; client/server came along, and you rewrote the application in a new tool, rewriting all the data integrity rules in the new client language. Hopefully by this point you could move the data integrity checking to the server, and hopefully you did. If not, when web-enabled became the vogue and you re-wrote your application in Java, you had to recode all the data integrity again...

Imagine: when your data integrity is fully protected by the database server, your applications can change or be replaced as often as you like, and your data integrity is guaranteed not to be impacted.

How agile is THAT?

--
Posted via http://dbforums.com