Re: Multiple specification of constraints

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news: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.

It is a lousy example, but if you can stick with it this "local constraint" (one that applies to this application related to the database, but not to other applications on the same data) is one that has me putting a dropdown list of values 2, 3, 4, & 5 for the user to choose from. Where did the application get those values? From somewhere in the non-database side of the application, I'm guessing. Why? Because I, the programmer, can control the constraints here so that when 6 becomes a valid value, I can change my dropdown list without anyone else involved. This has to do with human beings and how they work. Programmers will almost always do what they see as having the best quality solution from their perspective and that perspective is often at odds with what a dba would see as the best quality solution. If both could manage validation/constraint specification/logic within the same environment ...

Anyway, it relates to the same point I started with -- that the way we have our system development partitioned today and where we have our constraint processing handled, we end up with multiple specifications of validation/constraint handling. I don't think our systems should be partitioned the way they are, nor do I think the roles on the project team should be partitioned into dba's and programmers.

--dawn Received on Fri Mar 05 2004 - 22:49:09 CET