Re: Data Redundancy

dawn wrote:
> Marshall Spight wrote:
> >
> > Constraints aren't about something happening. If anything,
> > they are about something not happening.
>
> If nothing is happening with a declared constraint, then what's the
> purpose (that is rhetorical -- what I mean is: Of course something
> happens, verification, for example).

I didn't say nothing happens. However, with declarative constraints, what happens is abstracted away from the programmer viewpoint. With application-enforcement, the programmer has to attend to all of those details manually. This is why declarative constraints are inherrently superior.

> > > It's a perspective thing, perhaps?
> >
> > It can always be said to be a perspective thing: there are
> > perspectives that lead us to correct conclusions, and ones
> > that don't. There are valid perspectives and invalid ones.
> >
> > Anyway, it's pretty clear that you're missing my points.
>
> No, Marshall, in this case I do understand, but I disagree. On this
> one, perhaps you will permit me to be the teacher?

It is entirely possible that you understand what I'm saying, but so far I've seen no evidence of that. I would be more inclined to believe that you understand but disagree if we reached some point in the conversation where we saw costs and benefits on each side, but weighed theses costs and benefits differently.

Since the costs of declarative constraints are a proper subset of the costs of procedural constraints, this seems unlikely to happen. Perhaps you can identify a cost associated with declarative that I haven't, or a benefit to prodedural that I haven't. Note that anything of the form "better matches how I think" doesn't qualify, because that is entirely explanable by training in one vs. the other; it is a statement about the thinker, not about the thing being thought about. Many people will argue that iteration is easier to think about than recursion, but it's simply that they have years of training and experience with the one but not the other; this doesn't change the fact that the computational power of iteration is a proper subset of that of recursion.

> The issue of parameters and declarations compared to functions and
> process is age-old. We don't need to debate it any longer since it is
> a "two-sides of a coin" issue and I'm not trying to change you from
> data-centric to process-centric thinking, but get you to see that both
> are valid. Think of it as one of those foreground / background tests
> where you need to be able to move back and forth between them.

> Throughout the entire process of developing sofware we decide what to
> form into input/output (data) and what to form into process
> (functions). A constraint in a SQL-DBMS is input to a process that
> does something, otherwise it is worthless. I often see software
> development as treating software as a giant F(x) = y function,
> Computer(input) = output (which, quite naturally, gets me into hot
> water in this forum). As an alternative to this input -> processing ->
> output perspective is what mAsterdam occasionally reminds me is a
> data-centric perspective such as: capture -> data -> presentation.
>
> There is not something inherently better about either approach (your
> valid/invalid statement). There is something better about being able
> to see both.

I agree with pretty much the entire contents of the above. However I don't see it having anything to do with declarative vs. procedural.

Again: with both approaches, you have to understand the requirements; you have *specification.* With procedural, you have an additional error-prone step of translating the specification into executable code; you have *implementation.* (You also have maintenance.) With declarative,
you simply enter the specification into the system, the implementation is
written for you.

If you don't understand why this is a big deal, then you're not in a position to compare the two approaches.

Marshall Received on Fri Feb 17 2006 - 18:48:06 CET