Re: Declarative constraints in practical terms

dawn wrote:
> mAsterdam wrote:

>>dawn wrote:
>>>mAsterdam wrote:
>>>>dawn wrote:
>>[snip]
>>
>>>>>5) In the case of declarative constraints, they are necessarily
>>>>>employed by any application writing to the database.  In the case of
>>>>>metadata + code, each organization must determine whether and how to
>>>>>technically enforce business rules for all applications or enforce them
>>>>>through standards and QA approaches.
>>>>
>>>>One programmer error can ruin your data. No QA can prevent that.
>>>
>>>One (dba) programmer can damage data in either case.
>>
>>Yes. However, there is still this crucial difference:
>>Once correct constraints are enforced in the database,
>>it is not possible for a programmer to violate them by mistake.
>>The dbms does not do the update it was told to do, and
>>instead gives a warning. In the case where the validation is
>>done outside the database, programmer errors still may
>>(and will) ruin your data.

The "whatever framework" should be the only way to access the data for update in order to be effective. To the outside world this means that the "whatever framework" is in the database.

> In either case
> someone has the ability to botch things up, whether via the dbms
> specifications or database services code.
>
>

>>>In the one case
>>>more damage can be done by those writing the database services while in
>>>the other by those writing database constraints.  I don't know if one
>>>of these is harder to get right, harder to debug, or harder to include
>>>test cases for in regression testing.  Do sites often put their SQL
>>>constraint test cases into the same QA test harness as their OO or
>>>procedural code?

>>This is not primarily a QA issue.
>>It is about protecting valuable assets.

Several degrees of change management discipline are possible (BTW relying on QA testing is particularly bad IMO), but...

> I have not worked in a shop that fully utilized SQL constraint
> handling, but presumably constraints need to be added, changed,
> removed. This would introduce a risk that would be tested before being
> deployed, right?

Yes. One scenario: A constraint 'A' is supposed to be beneficial. A is added in testing environments, the system is tested. It's found to be ok. The constraint gets promoted, eventually into the production systems, but disabled. In the meantime some data cleaning actions take place. As soon as it is possible the constraint A is enabled.

> That is what my question was about. I don't know if
> new builds of the software run through regression tests for the dbms
> constraints as well as application code or not, typically (of course
> I'm sure there is variety).

[snip] Received on Thu Feb 23 2006 - 00:48:26 CET