Re: Data Constraints AND Application Constraints

From: FrankHamersley <FrankHamersleyZat_at_hotmail.com>
Date: Sat, 19 Mar 2005 23:27:55 GMT
Message-ID: <%z2%d.4106$C7.2419_at_news-server.bigpond.net.au>


Kenneth Downs wrote:
> 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!
>

Perl is fine for moi! Have seen the Foxplus attempt in a project I managed - it generated the base code (tables and navigation menu mainly) but ran out of puff thereafter.

Of course a perl freak would look at the perhaps limited range of techniques I use and lament that this or that sequence of operations could be done in a single statement...but it works, I understand it and can fix its bugs.

I have bizzare dreams that one day I might port it to APL! But that's only to secure the code from prying eyes ;-).

>>. 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?

This app has a work flow nature and not all constraining information is known or provided at the time a record is established. At the moment I am exploring the options triggers provide. Not set in concrete.

> Why do you allow externally crafted stored proc code?

ATM I prototype new functions in clear and then when functioning look at ways to shape them to suit the code generator. Going forward I expect there may be sprocs that are

> What are you doing for the GUI?

Base will be PHP, advanced will be Java. The panel layouts will be drawn from the database - totally soft.

>>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.

My experiment is not general purpose either as I expect only its creator could love it!

For me though its all or nothing - a instant tool that gets me to the plate but clearly won't assisting in reaching first is worse IMO than resigning yourself to build the required tools from scratch. I find the real payback benefit of this imperative is most apparent when the second release is proposed and the project team starts to catalogue all the gotcha's that will impede a smooth transition. If you are using waterfall/iterative process in the pre version 1.0 project it can onset even earlier. Of course the standard response is to architect in infinite detail before producing any code to avoid a premature return to GO (without collecting 200 roubles). Of course the Bazaar methodology seeks to avoid this risk by brute force...but then we all know and (happily) accept the goods bought cheaply in the bazaar are at risk of breaking on first use!

Cheers, Frank. Received on Sun Mar 20 2005 - 00:27:55 CET

Original text of this message