Re: Multiple specification of constraints

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c20eth$aq7$1_at_news.netins.net...
> Or you could partition the software application services in this way:
> a -- interface to user and/or "batch" (e.g. web services)
> b -- constraint/validation services
> c -- CRUD services
>
> whereboth a and c are clients of the b services.

I thought you wanted to get out of the business of having the GUI communicate with "something else".

> This means decoupling the CRUD services from the constraint services,

A relational language will buy you that... I agree with Bob that relations are not necessarily anything to do with persistence, although persisting them is useful for obvious reasons.

> while
> still ensuring that data that gets stored has been through the
> constraint/validation services. This possibly puts additional power in
the
> hands of the application developers to botch up the database in a big way,
> but it is not as if that isn't the case anyway.

Yes, but that doesn't mean we want even more exposure. We encapsulate things precisely because we can't remember all the details. Arguing for less of it, on the grounds that we can't catch EVERYTHING, is a misapplication of the Slippery Slope argument (as most applications of it are).

> Nothing guarantees accurate data

True, depending on how you define "accurate." You can at least guarantee that your data adheres to your definitions of it, however.

> but if we take a wholistic approach to data
> integrity where we want to give the best shot we can at capturing
accurate,
> meaningful, retrievable, validated, properly interpreted, etc data (not
just
> what is currently in the DBMS constraint specs) we will give it a good
shot.

A "good shot" is not good enough.

> Good data management crosses the entirety of a software application, not
> just the "backend".

I disagree. Certainly data crosses those tiers, but at the very least it can be the final executioner of Bad Requests. You still have the ability to define what "Bad" means.

> By no means -- I am not suggesting that we ditch the idea of applying
> database validation against constraint specifications AT ALL! I simply
> don't think we (as an industry) are taking a solid constraint/validation
> approach that makes for both data integrity and software development &
> maintenance efficiency & effectiveness.

Agreed - that's why I'm arguing for more relations and code generation from RDBMS constraints.

> An application developer could technically bypass the data integrity
engine
> and employ the crud services in a test environment, with my scenario.

More to the point: they might do so completely innocently. They might do so in the name of "efficiency" and "productivity," which they deem worthy business goals, at the expense of correctness. With a DBMS, they don't have that horrible option. It's an issue in development as well as production - I'd want to see those errors as early as possible.

> Decoupling, while still interfacing, CRUD services from data integrity
> services gives some advantages:
>
> 1) maintainability, one place to make integrity changes; local & global
> typing specified using the same tools

What do you mean by "local & global typing"? Otherwise, one place is good.

> 2) cost of development; potentially faster and better quality with fewer
> "people interfaces" (and if you have not seen any example of a poor
> interface between DBAs and software developers, ...!)
> 3) cost of ownership, stems from combination of 1 & 2

#2 isn't really an artifact of relational per se, but a lot of other

> 4) data accuracy, by taking a wholistic approach to data quality, it shows
> in the resulting software

Uh... I don't buy that. Even if I knew what you meant by "wholistic", I wouldn't buy it.

> GUARANTEES?? If the software application has "Date of Birth" as a "screen
> prompt" for an attribute that is treated as "Date of Skull Fracture" (my
> creativity isn't up right now, but you get the idea), then you test the ty
pe
> of the data all you want and your data is definitely corrupted!

Sure, agreed. But the existence of multiple attributes in the same domain doesn't imply the need for removing domains entirely...

• erk