Re: Data Constraints AND Application Constraints

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Sat, 19 Mar 2005 08:54:10 -0500
Message-ID: <uhntg2-htn.ln1@pluto.downsfam.net>

FrankHamersley wrote:

> -CELKO- wrote:

>> I agree with you about checking data at each tier.
>> 
>> But what I would really like is to have a "rules engine" that would
>> help me generate SQL check constraints as well as 3GL if statements.  I
>> would  also like to have my tool put the rules together in a decision
>> table or something similar so I can validate and optimize them.

>
> This is a most interesting comment in my context...as I am currently
> "tooling" around with a greenfield opportunity which will employ amongst
> other things an SQL DBMS (no surprises there).
>
> Because I am basically lazy (and want a life too), but have extreme
> paranoiac tendencies when trusting computers (actually I really mean
> their creators) to get it right, I reached a conundrum on how to produce
> lots of reliable code without employing an army of hungry slaves.
>
> The currently favoured solution has been to write a script (perl as it
> happens) that parses a very terse text file (basically a schema plus a
> bit more) and generate scripts (so far) for:

My history on that was:

Attempt -1: foxpro 
Attempt  0: perl
Attempt  1: C#  (some of this code survives in Attempt 3)
Attempt  2: Java (translated #2 and built)
Attempt  3: PHP, final.

Problem with perl for me is I can't read hieroglyphics (ducking). But I believe their motto is TIMTOWTDI!

>
> . database create and user defined types
> . table and index create (100% rerunable for easy schema upgrades)
> . triggers etc
> . stored procs for insert, update, delete, archive
> . ACL's
> . core static data (self description and other stuff)
> . it also places standard prefix and postfix statements on externally
> crafted stored proc code

What are your triggers for?

Why do you allow externally crafted stored proc code?

What are you doing for the GUI?

>
> As you might guess I eschew GUI based hacking in favour of a CLI style -
> just a throwback to my punched card days of building CDC OS's from
> source tapes!

Amen brother.

>
> The time to first gratification is of course a lot longer than clicking
> here or there but by golly does it scale up real fast when you want to
> add a new table or universally change some processing rule across the
> entire system!

Amen again.

>
> Of course there are no doubt tools out there that could do at least some
> of this

Key words "at least" and "some". Nobody does it all. If it is obvious to you and obvious to me, why isn't everybody doing it? It seems to me a reverse of Conway's law, that the organization of teams has become congruent to the organization of technology: the db/client split has created split teams that cannot process a change that would effect both of them with any serious impact.

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

Received on Sat Mar 19 2005 - 07:54:10 CST