Re: foundations of relational theory?

"Marshall Spight" <mspight_at_dnai.com> wrote:
>There are a number of problems that come from having
>applications enforce integrity. One nasty one is that bugs
>in the code translate into corrupted data.

This is true but I mention this more at length in another post to this subthread.

>Another is that the integrity code needs to be in
> every application, and can get out of sync.

You're not considering points from other postings here. Your comment is based on a (relational) database-centric view and not a (MV) application-centric view. We "generally" consider the application all-together as one unit. There is (usually) only application, though of course there are many modules in an app (A/P, A/R, G/L, O/E, etc..) In other words, there are no other applications to maintain to insure proper integrity syncs.

Now, one of the beauties of the Pick model, and a blatent falacy to those not used to it, is that anyone can write code that affects any data. This assumes that there is no security and that you have someone in the organization who has little expertise with the application and/or malicious intent. A Pick shop is no more or less inclined to such vulnerabilities as a relational shop - if there are inexperienced people in a shop and/or no security, all sorts of maliciousness can occur. The more common scenario for any shop is that you have developers who aren't authorized to work on the application unless they know something about it and the underlying data structures. This comes to the argument "guns don't kill people, people kill people". Therefore, don't blame the model for data corruption (any model), blame the people who corrupt the data by act or omission.

Tony Received on Tue Oct 28 2003 - 03:53:05 CET