Re: Multiple specification of constraints

From: Eric Kaun <ekaun_at_yahoo.com>
Date: Fri, 05 Mar 2004 21:07:31 GMT
Message-ID: <n_52c.21285$JZ2.1723_at_newssvr31.news.prodigy.com>


"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c2aoml$uik$1_at_news.netins.net...
> I think we agree that all constraints can be seen as constraints on the
data
> globally by simply narrowing the scope of the constraint. However, this
is
> what I have seen happen -- tell me if you do not think this is the norm:
>
> Data get specified in requirements, we normalize them and stick 'em in
> schemas, with constraints and all. Then somewhere in the life of the
> database, changes are made to the initial applications or new applications
> are built where the database constraints are necessary but not sufficient
> for taking in the data properly from a user, for example.
>
> Let's say that the developer and DBA get along (there have been cases, as
I
> understand it) and when a constraint allows for all real numbers to two
> decimal positions and it is determined that the requirements change so we
> are going to collect only whole numbers, the database constraints are
> changed. However, even this programmer, when coding a portion of the
> overall application that is used only by the xyz department where the
value
> of this attribute must be between 2 & 5 simply adds the logic into that
> application for this restriction rather than having any change made at the
> database level.

But if that application then reads data written by a different application, which wrote a 6, what happens? If that application WRITES only 2-5, fine... but the 2-5 range either is a restriction for the data domain or it isn't. What does it mean that the data "must be between 2 & 5"? That introduces a problem if that application and others are modifying the same data. What about the "old" values under 2 or above 5?

> Does this still happen in real software development today or am I stuck in
> the 80's? If it does, you might think that the answer is to get the
> programmers to do things right. Ah, but there are ways to provide carots
> rather than sticks even for developers. If a software developer can
handily
> change a constraint they write but can't easily change one they don't,
then
> guess what?

Either the meaning of the data has changed (in which case you have to cope with all the data already out there, or convert it), or the application is dealing with a more restricted set of the data (which is fine). It's not a local constraint - it's a query. Maybe I'm just confused by the example.

  • Eric
Received on Fri Mar 05 2004 - 22:07:31 CET

Original text of this message