Re: Declarative constraints in practical terms
Date: 22 Feb 2006 16:57:25 -0800
Message-ID: <1140656245.424719.152300_at_z14g2000cwz.googlegroups.com>
mAsterdam wrote:
> 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.
> >
> >
> > If the database services are used by application developers, then
> > couldn't inside-the-database constraints be botched up by developers
> > (e.g. dba's) just like outside-the-database services could be bothed up
> > by developers (e.g. database service/infrastructure programmers)? As
> > long as applications use whatever framework is in place for maintaining
> > the database, then the constraints will be applied.
>
> 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.
Yes, related to add/update/delete, but reads (e.g. selects) need not go through the database services, in general.
>> >>>constraint test cases into the same QA test harness as their OO or
> > 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
> >>>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...
relying on after-coding testing is bad, ensuring there is such is good. [Aside: I didn't use the term "QA" in the response since many QA professionals would suggest their work on a project starts when the project does and is not just in a testing phase after code has been written.]
>> > removed. This would introduce a risk that would be tested before being
> > I have not worked in a shop that fully utilized SQL constraint
> > handling, but presumably constraints need to be added, changed,
> > 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.
Reading between the lines, it sounds like dbms constraint changes often happen outside of project product build, versioning, and deployment processes, perhaps as a parallel project effort. I'm sure it all works fine, but I haven't been around a shop where the code for database changes was not bundled with the software requiring the changes since the era when software was not built regularly. I'm just thinking outloud on this -- I don't really have a point, just want to be sure I'm understanding this right.
Cheers! --dawn Received on Thu Feb 23 2006 - 01:57:25 CET