Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

From: Marshall Spight <mspight_at_dnai.com>
Date: Wed, 20 Oct 2004 16:08:16 GMT
Message-ID: <Q3wdd.217587$wV.174119_at_attbi_s54>


"Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:b2f3lc.8t6.ln_at_mercury.downsfam.net...
>
> Laconic2's reply with Marshall's reply to that actually gives the insight
> better than I have: you want to provide the constraints structurally.
>
> I'll do the details here.
>
> CASE 1: CONSTRAINT SALARY <= 100,000 (from your other post).
>
> All discreet finite range constraints can be converted to RI by having a
> table of allowed values. Salary codes with dollar values (or direct salary
> values in a table).
>
> Some will knee-jerk react against the idea of a table with 100,000 rows, but
> of course that is silly, we only enter the ones we are going to use.

I must say I am impressed with your creativity. However, I find this exact solution unsatisfying, but I have a *related* idea which you may find interesting.

What if we could *declare* a set according to its properties (constraints, really) and use them as if they were regular sets? So we could have a set ValidSalaries that was declarad as the set of all integers between 0 and 100,000?

> Advantage 1: With a constraint, policy changes require a programmer. Now
> you are truly Constrainticus, preventing things from getting done. If the
> salary values are in a table, policy changes can be implemented as soon as
> they are authorized, the top dog goes in and types it in. Keeping to the
> Greek philosophy idiom, this is much more virtuous, i.e, it conforms to The
> Good.

I dunno. If the constraints are declarative and not procedural, the change is about as easy either way.

> Advantage 2: The RISC/CISC argument. Putting in a constraint requires a
> new primitive, the column constraint, to do something that could have been
> done with the existing unique/referential primitives. This means guidelines
> on when to use a column constraint, policies on creating, modifying, and
> changing them, upgrade procedures to ensure implementation, creating a
> unit test system, creating an integration testing system, etc, etc.....

I hear you, but I also note we could do all the boolean logic we need with just NAND. And yet, AND and OR are quite useful.

Marshall Received on Wed Oct 20 2004 - 18:08:16 CEST

Original text of this message