Re: One Ring to Bind Them

"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message news:<j$hPkhMcm30AFwso_at_thewolery.demon.co.uk>...

<snip>

> And I think that you've missed Bill's point. Predicates describe
> relational data. So Eric's point holds. But relational ASSUMES that
> relational data can be used to describe the real world - it's an axiom.
> Bill doesn't think that that holds in the real world, and I don't either
> which is why I asked the original question that started all this. Logic
> (ie predicates) is great for showing that a position is self-consistent.
> It is useless for showing that that position is relevant or useful.
>

Well, that's that darn "closed world assumption" again. Famously, you may assert that "the King of France is bald". But as far as I know no automatic logic system can tell that that's a total fib - unless you want to wire your systems up to Google or Yahoo, in which case you've abandoned any sense of a logical basis for what you're up to. Consistency is (I will hedge and say probably) the best you can achieve - correctness is beyond any automated logic system I'm aware of. As an aside, if this isn't good enough for you, what would you prefer to base your database systems on ? Intuition ? Appeals to authority ? Artist's impressions ?

> But are you storing your constraints as a trigger? (Which I would
> sort-of consider an application in itself.)
>

Oh god, here we go with storing things and triggers. How dully procedural ;)  

> As I understand "the database", in order to store constraints in the
> database, you must store the constraints as *meta*data. Which means your
> end-user developers (programmer, dba, whatever) MUST be able to program
> *inside* the db engine so it can recognise metadata.
>

Ummm, no. The constraints would go in the catalogues, so they just appear as data too. What do you mean by "*inside* the db engine" ? Even if/when I get the source code to a DBMS server, I wouldn't expect to be updating that to add constraints !

> At which point we get user-defined data types and your relational database
> has started down the road of mutating into an object database :-)
>

Umm, no not really - it would just be turning into a relational database. Bit of a non sequitur though (constraints -> metadata -> user defined types ?)

> Actually, I've just reread what you wrote. Do you mean "constraint" as
> in a relational constraint - foreign-key type stuff; or as a general
> term for enforcing integrity. I was thinking the latter, hence my
> reference to triggers, but I suspect you might be meaning the former. If
> you did mean the former, Pick doesn't have them because it achieves the
> same effect as a side-effect of its implementation. So the fact that
> relational needs them is de-facto a hindrance relative to Pick.
>

I would like to know your differential between a "relational constraint - foreign-key type stuff" and "a general term for enforcing integrity". How do you partition your constraints into those categories ? Personally I view a constraint as boolean expression that must never evaluate to false. Some are called "general constraints" or "assertions" because they can refer to arbitrary combinations of columns from tables, others as "base table" or "column" constraints because they refer to one particular table. (In addition to the most fundamental constraint of course - that of declaring the type of each column.)

> Cheers,
> Wol

Cheers !

• Tony