Re: A real world example

Brian Selzer wrote:
> How so? In what way does the information principle require that attributes
> be mutable? A relational database contains knowledge about things, not
> things. Now, if you're going to talk about something, then that thing must
> either exist or have existed in the universe.

Referring to "things" and "entities" may be part of the problem, as it's on the slippery slope to First Great Blunderville. Facts are facts, and don't change, though our understanding of them does. A database state is simply a set of propositions, which uses predicates (relations) as the organizing principle. Constraints keep our propositions consistent, with respect to identifiable values. I don't think there's any necessity for a group of facts in one database state to be somehow traceable to a previous one. I could certainly be wrong; it just feels to me like this discussion is pivoting on identifiable "thingies," rather than logical constructs.

> If a thing exists in the
> universe and is relevant to the discussion, then there must be some way to
> distinguish that thing from all other things that exist, that have existed
> and that can exist, otherwise there isn't any way to be sure that you're
> talking about the same thing in successive database instances.

Why does one have to "talk about the same thing" in successive database instances (values)?

> It is often
> necessary to know what was known about something in order to assert
> something new. For example, when a credit card charge clears, the bank must
> know the balance of the account in order to compute the new balance.

Maybe, but from a functional standpoint, that operator is just a function (e.g. "subtract $500 from X), in which the balance is a free variable. Only in an imperative world does that involve "knowing" (referencing) the "previous" balance. Function application means there's no "query" of the value prior to the update.

> More
> importantly, the bank must be able to identify the account that is about to
> change, and that identity must remain constant in both the preceding and
> succeeding database instances.

Why? As long as it can be identified via some query, what difference does it make? For example, if I make a database schema change and introduce a new key, with appropriate view changes to support old application code, is there some logical distinction? If the external queries all still produce the same results, excepting the specific values being updated, what does "identity" have to do with it?

> Because changes are set-based, without some
> means to correlate the propositions in the preceding instance with those in
> the succeeding instance, you cannot be certain that you're talking about the
> same thing;

There is no "thing." These are propositions, or assertions if you like, nothing more. The only meaning is in the correlation of queries to external phenonema of interest.

> therefore, you cannot be certain if the succeeding instance is
> correct. The question is: should the solution to this problem be handled in
> implementations, or should the theory be strengthened to eliminate it?

What "strengthening" would eliminate the "problem"?

> I believe Codd used the term "permanent" to describe surrogates. That
> implies immutability. He did mention drastic circumstances, such as merging
> databases that could require that they change, but the impression I got was
> that they should be permanent.

"Impression," "should," and "implies" are all insufficient explanation - if I missed your solution in a previous post, let me know, but Codd's writings aren't (especially in cases like this where there appears to be room for interpretation) holy writ.  

• erk