Re: Data Constraints AND Application Constraints
Date: Sat, 19 Mar 2005 08:54:10 -0500
Message-ID: <uhntg2-htn.ln1_at_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_at_(Sec)ure(Dat)a(.com)Received on Sat Mar 19 2005 - 14:54:10 CET