 | |
#181
 
| |||
| |||
|
Re: Separate PK in Jxn Tbl? -
02-02-2008
, 07:57 AM
|
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. |
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.
#182
| |||
| |||
|
|
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. |
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.
#183
| |||
| |||
|
|
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. |
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.
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.