Re: One Ring to Bind Them

In message <bcb8c360.0406210246.15901eda_at_posting.google.com>, Tony Douglas <tonyisyourpal_at_netscape.net> writes
>"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 ?

What would I prefer to base my database systems on? Well, actually, I'd like to base them on science. On some evidence (which by its very nature, must be experimental and statistical) that says it's actually relevant to the real world.

Anything that relies solely on logic (whether automated or not) is useless. If we relied solely on logic then both Aristotle and Galileo would be right, as would Ptolemy and Copernicus (and with hindsight we would laugh BOTH the latter two out of court, despite BOTH of them having impeccable logic. Because we have "experimental" evidence that tells us their models are irrelevant. "correctness" doesn't come into it). Logic merely shows that your theories are self-consistent. But what do you do when you have TWO theories, both of which are logical and self-consistent, but are mutually inconsistent? If I took your argument at face value, I would have to believe both ...
>
>> 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 !

That was why I made the comment about "user-defined types". If you define something as an integer, it is enforced by the database. If you define something as "someone's age", it cannot be negative, and it can have the values "unknown" and "dead".

So we now have the position that either you do some of your "type-constraint"ing inside the database and some outside, or you have to have some way of pushing the validation "inside" the database.
>
>> 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.)
>

I've mentioned it elsewhere, but I see two types of integrity. What I call "natural law" and "statute law". Statute law says you can't have a car without an owner, but either can cease to exist without affecting the existence of the other. That was the general term - the latter of the two I was thinking of. Natural law says the existence of one depends on the existence of the other - you can't have an invoice detail without having an invoice for it to be part of. I should have said "enforcing integrity between tables". In that case, MV simply allocates the same primary key to both - if the primary key goes, everything else goes with it :-)

And MV doesn't constrain the type of each column :-) I'd like to be able to do something like that, actually, but I'd rather validate than constrain :-) Is it relational that enforces strong typing, or just current implementations? Either way, I think it's wrong. But MV is untyped and that's as bad the other way :-) - I would love the *ability* to enforce typing, I just don't think it should be *mandatory*.

Cheers,
Wol

-- 
Anthony W. Youngman - wol at thewolery dot demon dot co dot uk
HEX wondered how much he should tell the Wizards. He felt it would not be a
good idea to burden them with too much input. Hex always thought of his reports
as Lies-to-People.
The Science of Discworld : (c) Terry Pratchett 1999