Re: Separate PK in Jxn Tbl?
From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 02 Feb 2008 14:57:03 +0100
Message-ID: <47a47545$0$85796$e4fe514c_at_news.xs4all.nl>
>> Brian Selzer wrote:
>>
>>> Constraints should always be checked by the DBMS,
>>> not by applications. If you have two separate applications
>>> that manipulate the same table, and one enforces one constraint
>>> while another enforces another, then all you need to do to
>>> bypass one constraint is to use the other application!
>>> What, then, is the point of even having the constraint?
>>
>> I think that application constraints and database
>> really constraints are two entirely separate things.
>> The fact that they may be structurally identical obscures
>> and confuses this point. (Hence Brian's entirely
>> reasonable rhetorical question above.)
>>
>> What, indeed, is the point of having one application and not another
>> enforce a constraint, *if we view this from the perspective of the
>> requirements of the database* Clearly there is none. However
>> individual applications may have requirements that are best
>> implemented as constraints *within the application.* I call these
>> "application constraints" because they are specific to the
>> application. They are *not* integrity constraints, even if we
>> are using identical mechanisms (in different locations) for both.
Date: Sat, 02 Feb 2008 14:57:03 +0100
Message-ID: <47a47545$0$85796$e4fe514c_at_news.xs4all.nl>
James A. Fortune wrote:
> Marshall wrote:
>> Brian Selzer wrote:
>>
>>> Constraints should always be checked by the DBMS,
>>> not by applications. If you have two separate applications
>>> that manipulate the same table, and one enforces one constraint
>>> while another enforces another, then all you need to do to
>>> bypass one constraint is to use the other application!
>>> What, then, is the point of even having the constraint?
>>
>> I think that application constraints and database
>> really constraints are two entirely separate things.
>> The fact that they may be structurally identical obscures
>> and confuses this point. (Hence Brian's entirely
>> reasonable rhetorical question above.)
>>
>> What, indeed, is the point of having one application and not another
>> enforce a constraint, *if we view this from the perspective of the
>> requirements of the database* Clearly there is none. However
>> individual applications may have requirements that are best
>> implemented as constraints *within the application.* I call these
>> "application constraints" because they are specific to the
>> application. They are *not* integrity constraints, even if we
>> are using identical mechanisms (in different locations) for both.
> > I think you're on to something. Making a distinction between database > constraints and application constraints helps me clarify my thinking. > Being able to "reflect" database constraints to keep applications in > synch with changes sounds like a great idea.
Have a look at purpose.
Constraint enforcement is to protect your data.
Restrictions in the user interface are there to assist
the user providing data. It is for data-capture efficiency.
My 2 cents. Received on Sat Feb 02 2008 - 14:57:03 CET