Re: One Ring to Bind Them

In message <slrncd4mtn.e2r.choess_at_force.stwing.upenn.edu>, Chris Hoess <choess_at_stwing.upenn.edu> writes
>> You state no (I think). I state yes! There is a tremendous cost advantage
>> for my position, but as I've said before, cost is not an issues in all
>> scenarios. The view that the RDM is more useful is tautological. In other
>> words, a primary axion is: it is. So one has no alternative but to conclude
>> so.
>
>Huh? I think you've missed Eric's point. As he said, the relational model
>is based on predicates: sentences which make a single, descriptive
>assertion. I confess that I don't fully understand the correspondence
>between Pick internals and parts of speech, but the point is clear
>nonetheless: our task in compiling databases, as I see it, is to be able
>to accurately describe relevant parts ofthe world and draw inferences from
>those descriptions. It is from this premise that Eric's conclusion
>follows: the best model for making descriptions of things is that whose
>basic unit is description.

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.
>
>I'm not 100% sure how it follows that storing constraints in the database
>of necessity results in a disadvantage in costs. As I just posted in
>another followup here, the constraints themselves are easily accessible to
>the applications given a good system catalog. For that matter, it doesn't
>follow that the constraints must be presented exactly as represented
>internally in the database. It seems to me that it should be possible to
>make a 1:1 mapping of some terse, "programmer-friendly" language into a
>more English-like statement of the constraint, suitable for checking by
>"domain experts".
>
But are you storing your constraints as a trigger? (Which I would sort-of consider an application in itself.)

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. At which point we get user-defined data types and your relational database has started down the road of mutating into an object database :-)

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.

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