Re: Data Constraints AND Application Constraints

David Cressey wrote:

>
> But I think you are possibly about to slip into one of those definition
> potholes.

Yup. But it may yet yield more productive discourse (fingers crossed).

>
> I'd like to suggest that "software" consists of data definitions, and
> prescribed actions on that data.
> I'd like to suggest that constraints are really proscribed actions on
> data. As such, they can become part of the data definition.

Despite your correction, this is still correct enough to be crucial, especially "they become part of the data definition." Our technical reference begins with this statement:

"All business rules resolve to database specifications."

IOW, everything the customer could possibly ask for turns into some rule about or action upon data. We all know this, but we deal with the knowledge differently.

Now, if we've been writing db software for decades, those millions upon millions of lines of code, all those tables, must follow patterns. If they do, those patterns become the structure of your data dictionary, or the syntax of your declarative language.

So the "meta-data" or the specs or whatever you call them include things like

detail.extended = detail.price * detail.qty order.lines_total = sum(detail.line_final)

>
> The question of whether this part of the data definition is or is not
> meta-data is really a question of how the constraint is expressed.

As per above, I would argue that the definition or specification exists outside of its implementation.

> There
> are some database engines that have a really nice model of constraints,
> stored as meta-data in system tables. At least, they seem really nice to
> my untutored mind.

If you are willing to stray a little off the beaten path, you can "go backwards" and express the constraints in triggers. This reduces the entire build process to an assembly process, piecing together snippets of code that express certain constraints.

It is also important to get down to the smallest number of constraint types that can express any possible constraint.

>
> But the fact that constraints are part of a shared body of data
> definitions (data dictionary?) is really more fundamental than the
> question of whether or not they are meta-data.

Exactly.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth_at_(Sec)ure(Dat)a(.com)