Re: Unique Keys

Kenneth Downs wrote:
> Tony Andrews wrote:
> > Mikito has given an answer that works, but as you say does not use
a
> > unique constraint (how could it?) But I think you are looking at
this
> > the wrong way round: a unique constraint isn't primitive, it is a
> > shorthand for a constraint that could be more generally expressed
as:
>
> This is an interesting paragraph. I would not have said, "unique is
> shorthand", but it does actually express the idea, a declarative
constraint
> invokes a lot of procedural code inside of the server tha we never
see, we
> just see the effects. But anyway, unique constraints are
declarative, and
> Mikito's is not, Mikito's stands as a *special* *case* that requires
a
> programmer to code up some SQL instead of simply specifying the
unique
> constraint in pure scalars.

This is where you and I fundamentally disagree. As far as I am concerned, Mikito's constraint IS declarative. It declares a condition that must always be true, and does NOT specify in procedural code how that constraint should be enforced. It defines "what" not "how" in other words. Your personal definition of declarative seems to mean "requires no knowledge of syntax". That may be a laudable aim, but it is not what "declarative" normally means:

http://en.wikipedia.org/wiki/Declarative_programming

> The answer I came up with, and that I am using, allows me to
declaratively
> specify[1] the start/end combination as being a unique primary key,
and
> more importantly, to define foreign keys into it that do not require
the
> "run out". Because I use a code generator, this will generate code
that is
> superficially close to Mikito's, but different in many respects (most
> importantly that no programmer has to write it). Probably
> the most crucial respect is the ability to present a foreign key that
can
> be used without introducing ad-hoc code in every query.
Are you going to tell us how you do it? I still don't get it. Received on Thu Nov 25 2004 - 16:14:52 CET