Re: Database design, Keys and some other things



Marshall Spight wrote:
mAsterdam wrote:
Marshall Spight wrote:
The snipped questions weren't purely retorical.
They pointed in another direction.
Many interesting things happen at boundaries - but they
are interesting only to people who are interested.

Here are the snipped questions:

What does exist oustide the minds of the users? This
relationship is a shared illusion. How did it come into being?

There is a category of questions for which their defining characteristic is that we can make no observations to test hypotheses about them. Is there a God? What happens when you die? Is there an objective truth outside of my subjective perception?

Putting them in one list doesn't make them of the same order. "Is there a God?" - off topic. "What happens when you die?" - off topic (digression: except maybe that a database contains dead objects in the sense then as soon as they are in the database they stop behaving - food for another thread). "Is there an objective truth outside of my subjective perception?" - is of a different nature thought some refinement is necessary.

The design of a database is for a large part the
creation of a shared illusion: let's put facts in a
container. The predicates are the types of fact we
are going to accept, the propositions the thruths
we agree are relevant to our business. You won't get
money from your ATM if you can't trick your bank into
believing that it is you there, and that they have a
good reason to let you have that money. They wil check
some of their facts to establish that reason.

Or this: "I can't help you sir, you are not in
the computer". An ICT worker deals in thruths,
lies and semi-thruths.

These questions are big, big questions, no doubt. However,
what makes a question interesting to me is, to what extent
can cogitation, observation, discussion, and experimentation
lead to a better understanding. So these big, big questions
are not in any way interesting. They are the philosophical
equivalent of an infinite loop: fun to look at for a short
time, but they quickly become boring, because no progress
can be made on the problem.

I'm with you on avoiding those loops.

My favorite quote in this area comes from Jack Vance
novel. Maybe it was "The Dying Earth." A mixed group of
pilgrims and travellers were sitting around a campfire, and
each in turn gave a description of his cosmology. At last
they turned to Lodermulch, and said, say fellow, you have
been quiet all through this. What is your idea of the
universe? And Lodermulch said, "Observe this rent in my
garment. I am at a loss to explain its presence. I am
even more puzzled by the existence of the universe."

Followups to comp.databases.metaphysics

Okay. It strikes me, though, that this leads directly
to a refutation of the idea that there's any essential
difference between the industry standard external
identifier and the database-specific surrogate key:
it's a matter of context merely, and not anything
intrinsic to that data, or how it is managed.

Emphasizing your /only/ in "only in the minds of the users" and /merely/ in "a matter of context /merely/", I'ld say the minds of users and context are as essential as it gets.

What would be essential in your view?

The question is: essential to what?

Essential to database design.

We were discussing whether there was a difference between
the natures of external ids vs. surrogate keys. What is
essential to this question is what their nature is. Generally
we do not regard context-specific considerations as essential.

It matters wether data come from the outside or from the inside of the system - the context of the data. .



Relevant Pages

  • cdt glossary 0.1.4
    ... This glossary seeks to limit lengthy misunderstandings ... basic database research and mathematics. ... When context matters, it is provided. ... It is /not/ the same as a reference. ...
    (comp.databases.theory)
  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... Yes, that's all facts are, though constraints mean that your facts are ... model already allows surrogate keys. ...
    (comp.databases.theory)
  • Re: America now has 57 states (plus Alaska and Hawaii)
    ... Hawaii and Alaska, IIRC. ... Let me know when you know the facts. ... Obama error about the states was the context - nothing else. ...
    (rec.sport.football.college)
  • Re: A real world example
    ... If a constraint is defined in terms of successive states of a database, ... facts cannot be thought of just in terms of instances of predicates. ... Yes, that's all facts are, though constraints mean that your facts are ...
    (comp.databases.theory)
  • Re: America now has 57 states (plus Alaska and Hawaii)
    ... Hawaii and Alaska, IIRC. ... Let me know when you know the facts. ... Obama error about the states was the context - nothing else. ...
    (rec.sport.football.college)