Re: Database design, Keys and some other things

JOG wrote:
> I think it comes down to the fact, it is easy to confuse a predicate
> with the situation it describes, but there is a real difference.
> Consider the predicate:
>
> "The sky is blue in the daytime"
>
> This has may be represented a a set of three items {sky, blue,
> daytime}.

I am sorry to say but you are confused. 'The sky is blue in the daytime' ain't no predicate. It's an [ambiguous] proposition which could be false or true if it were not ambiguous. It may be useful to know that the predicate's interpretation is not just any set, but a mathematical relation. What relation are talking about ?

>But we can say some extra things about this set. First who
> stated it - me. Second when it was stated. Third that it is the first
> thing I have said on the matter. Fourth, we can comment on the truth of
> the statement - that it, in england, is only true.. say 25% of the
> time. tops.

I am not sure what you are trying to say here.

>
> Now these are all pieces of information about the PREDICATE itself, not
> the situation it describes. They are metadata, and encoding them with
> the information about the situation is entirely incorrect - they are
> attributes of the container, not of the content.
>
> Mathematically we might write:
>
> P = {"sky", "blue", "daytime"}
> Author = {(P, "James")}
> Created = {(P, "27th Sept 2005")}
> etc...
>
> Saying { sky, blue, daytime, James, "27th Sept 2005", 25% } is wholly
> wrong. It is a confusion of data and meta data.

That's a confusion allright, but of a different kind.

>
> A surrogate key, created specifically to represent a statement, is no
> different. It is an artificial way of referencing the predicate. This
> is meta_data about the predicate and has no place existing in the same
> area as the elements of the predicate - the real information, that
> exists in the real world.

This just does not make any sense. Received on Tue Sep 27 2005 - 19:42:18 CEST