Re: foundations of relational theory?

Marshall Spight wrote:
> "cmurthi" <xyzcmurthi_at_quest.with.a.w.net> wrote in message
> news:3F9C53BD.4030006_at_quest.with.a.w.net...
>
>> Yes to the last; the integrity is up to the application.
>
>
> 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. Another is that the integrity code needs to be
> in every application, and can get out of sync.
>
> Marshall
>
Yes, absolutely. In all the years I've worked with Pick, I've always tried to get across the concept of having the integrity constraints (or validations as we tend to call them) in one place. Pick by its nature has none inherently. I like to think of the "application" as having several layers, the bottom of which enforces integrity. On Pick applications, therefore, if designed with this in mind, one could consider this lowest layer as part of the database schema, albeit under the control of the application programmer(s).

It would be nice if Pick had a true schema; several Pick licencees about 10-12 years ago started on this but due to the fragmented nature of the licencee's structure, the competitiveness among them and a lack of strong direction from the parent Pick Systems organization, not much was done.

I have to raise the issue of practicality again here. Pick by its nature is easy to use, program and maintain. So issues of integrity constraints, while theoretically perfectly valid, are simply considered more of a maintenance problem to be dealt with as situations arise. Anathema to cdt-ers, perhaps, but, as we keep hammering away, perfectly successful in the world we reside in. Many Pick shops have one or two programmer/analysts managing a medium sized company; many Pick software shops employ in the tens, not hundreds. So as a practical matter, ensuring data integrity is not too hard.

Chandru Murthi Received on Mon Oct 27 2003 - 15:59:12 CET