Re: Data Constraints AND Application Constraints

FrankHamersley wrote:

> So the question restated is how much trust should you put in the layers
> above and below? My view is that trusting any other layer - even a
> fully constrained database - is "fair weather" programming.
>
> IMO this poor kung fu leads to inherently buggy or tragic performance
> outcomes much like the parlourous security profile exhibited by the most
> commonly used x86 OS.
>
> Personally I always build for Roaring Forties and Southern Ocean
> conditions (when I can get away with it and often even when I can't)
> because when the "sh:t hits the fan" my code at least squawks loudly
> about where the fault originated from and can often typify it well
> enough to lead to a permanent repair or at least a better recovery
> outcome.
>
> Cheers, Frank.

I think Frank that you are addressing some of the basic realities of software development, the problems of errors found after go-live, dependence upon third parties, and so forth. Worst of all, our lack of a crystal ball.

I would reiterate the tremendous value of inexpensive iterative development, you address bugs the same way you did development, with a quick turnaround of a revision, ideally in hours with same-day service.

Another big idea that you don't hear much about anymore in this age of double-plus-buzzword marketing is the min/max principle, utilize the minimum number of components to maximum effect, a sort of RISC philosophy applied to the entire architecture. This is most notably NOT a characteristic of that popular x86 OS.

The fewer well-tested elements you depend upon, the stronger the application. Back when I did C/S with Foxpro, we knew that use of their macro substitution was slow and prone to causing the runtime to fail with an untrappable error, so the answer was to not use it. One time I found myself in a shop that had used it for *everything*, and ouch ouch ouch that thing crashed everywhere.

There are fascinating implications when taking the min/max philosophy principle to database design. You ask, what is the smallest set of primitive elements that will allow complete expression of any business scenario (as far as we know anyway), and you find you don't need that much, primary keys, foreign keys, automation (extended=price * qty) and comparison (total orders may not exceed credit limit).

Fewer elements means fewer unit tests, and as integration tests go as the factorial of the number of unit, every unit eliminated is a huge win for the testing.

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