Re: foundations of relational theory?
Date: Tue, 28 Oct 2003 22:40:08 GMT
Message-ID: <cfCnb.5674$Px2.3830_at_newsread4.news.pas.earthlink.net>
Lauri Pietarinen wrote:
> Jonathan Leffler wrote:
>
>> cmurthi wrote:
>>
>>> Marshall Spight wrote:
>>>
>>>> I'd still argue that a declarative integrity enforcement
>>>> system is better than a procedural one.
>>>
>>> Can a declaration enforce a really complex oonstraint? And if so,
>>> does the declaration begin to look like a procedural statement? For
>>> example, even on a simple level, how would you declare that Field1
>>> has to be conditionally based on Field2 and Field3, eg, procedurally,
>>> if(field3=='') field1=field2 else field1=field3.
>>
>> Using the Informix dialect of SQL, and ignoring SQL NULL values (since
>> they make a mess of everything), you could do:
>>
>> ALTER TABLE WhatNot ADD CONSTRAINT ((field3 = '' AND field1 = field2)
>> OR (field3 != '' AND field1 = field3));
>>
>> You could give the constraint a name - though ISO SQL and Informx
>> manage to do that differently. You could also include that
>> declarative constraint in the CREATE TABLE statement.
>>
>> I don't regard that as a particularly complex constraint. I'm not
>> sure that it is part of a good database design, but that is probably
>> simply because it is illustrative rather than anything else.
>>
>> The big advantage of the declarative constraint is that the DBMS
>> enforces it. No application can violate it, whether accidentally or
>> on purpose. If the constraint becomes obsolete, then you drop it.
>> Altering it is a two-stage drop and add operation (which Informix
>> permits you to do in a single ALTER TABLE statement, so there is no
>> window of vulnerability while you are changing the constraint).
> > > The problem with constraints like these is that, yes, you safeguard your > db from corrupt data, but getting the information back into the > application is not that easy: you have to parse the error message, get > the name of the constraint and translate it into a meaningfull error > message for the user. I don't know if anybody does this, so, in effect > you end up coding the same checks twice: in the app and in the db. > > This is where we run into the frustrating "mismatch" between app > language and db environment.
Hmmmm, well yours is probably a slightly clearer exposition than mine, but way back an aeon ago in this thread, I commented on exactly this phenomenon.
Let's see...ah, there it is...groups.google.com...Oct 13...
-- Jonathan Leffler #include <disclaimer.h> Email: jleffler_at_earthlink.net, jleffler_at_us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/Received on Tue Oct 28 2003 - 23:40:08 CET