Brian Selzer wrote:
A very bad design from my perspective as well.

Correct (if I understand). What does it mean that a list is a key? If
I change one value in the list, does that make it a new key? I would
think so.

Although I did just learn the benefits of redundancy from Frank ;-)

It might model a proposition something like

The team with people whose ID's are 112233 and 123456 has a best run of
38 seconds in the potato sack race.

Most data modelers would choose to provide a team identifier rather
than implement a multivalued ID (even MV developers).

Cheers! --dawn

Brian Selzer wrote:
I reject this point of view. The system I am building has values
and variables only. There are no pointers, there are no addresses,
and there is no concept of identity. There is only value.

This is not to say that the concept of identity is not consistent.
It certainly is, and useful programming languages have been
built on top of it. It is foundational to OOP. However, useful
systems have been built without it as well; it is not a necessary
concept.

I don't think identity is a concept with much useful life left in it.
Identity only makes sense relative to some address space,
and the world is shifting to distributed computing. There are
those who think that we can shift to a global distributed
address space, but I believe such efforts are doomed to failure.


Marshall

dawn wrote:
If we substitute "int" for "list", what does the above look like?

"What does it mean that an int is a key? If I change one bit in the
int, does
that make it a new key? I would think so."

I agree with both the list and the int version of the sentence. After
all,
why should the particular type of the key change the way key values
behave?


Sure, that seems like a fine proposition to me.


As would I.

But again, in my view it's not generally a language designer's job to
try
to dictate best practice. I instead like the idea of orthogonal
features,
and recursive definitions. I like to make as many things as possible
have
first class status in the language. (Although I draw the line at first
class
variables a la SML, since that introduces identity.) If I decide that
lists
shouldn't be keys, I'm going to have to put special purpose code in
just
to check for that, or else build a more complicated, more rigid model
that simply can't express the idea. Neither appeals to me.


Marshall

dawn wrote:
If I change the order of the items in the list,
does that make it a new key? I would think so. (See below)

The team with people whose ID's are 123456 and 112233 has a best run of
38 seconds in the potato sack race.

Would be the same proposition, right?

So, in this example we have a set-key, not a list-key.

mAsterdam wrote:
Yes, I too often mix sets & lists when I think in terms of the MV data
model, which has only list attributes in which conceptual sets & lists
are both implemented.

Yes, unless we add to the proposition so that it matters who's on top
-- perhaps that person is the lead person, the one we want to contact,
the one whose left leg is in the sack, the parent...

Cheers! --dawn

dawn wrote:

Really? Are sets implemented as well? I thought it was more like this:
When you have a model only supporting lists (e.g. XML) you have
no choice but to implement any multi-value thingy as a list - wether
you initially thought of it as a set or not.

mAsterdam wrote:
Sure. If you change the order of the bits in the int,
that makes it a new key as well.

If you make a logical change to the value, it's a different value.
(Likewise, if the logical value stays the same but something
else changes, it's the same value.)


Uh, yeah. You're right. That's a set, not a list. *cough*


Marshall

"Marshall Spight" <marshall.spight (AT) gmail (DOT) com> wrote

What about the list of operations and materials that are required to produce
a part? That certainly has identity.

I disagree. It is a necessary concept, not only externally but also
internally. An entity must have identity, otherwise there's no way for the
database, or users, for that matter, to distinguish between them. That's
the whole point of keys. Because a key value determines all other attribute
values, it identifies an entity. But a there's a problem: a key value may
change over time, so any given key value's ability to determine what was or
is known about an entity is limited to a specific interval, bounded by the
time that its value became known by the database and the time that a new
value became known. This imposes limitations on the types of updates that
can be performed or the types of constraints that can be enforced. If all
keys can change, then either updates must be singular, that is, must affect
only one entity of any given type at a time, or no temporal constraint (a
constraint that involves the state of the database at more than one point in
time) can be enforced. This is a significant limitation of the Relational
Model with which I am most familiar, but I suspect that the concept applies
to all other data models, which may have means to overcome it. In the
Relational Model, all updates are set-based, and if all keys are subject to
change during an update and if the cardinality of the update is greater than
one, then there's no way to determine which tuple in a new relation value
corresponds to any given tuple in the original relation value. It should be
obvious that correlation is necessary to enforce a constraint that involves
more than one database state. Therefore, the only mechanisms available in
the Relational Model to enforce a temporal constraint are either to limit
updates so that they can only affect a single tuple in each affected
relation, or to prevent updates that do not hold at least one candidate key
constant in each affected relation.

This limitation is overcome by revealing as an attribute the identity that
is intrinsic to every proposition in the database. Every proposition must
necessarily be different from every other proposition, because either
something is known, or it isn't: the knowledge contained in a database is a
set of propositions, not a collection. Thus every proposition has identity
with respect to the state of the database at any specific point in time, and
that identity can be revealed as an attribute. In order to avoid losing
information over time, every new proposition must have a new identity value.
By that I mean that new values exist only for propositions that are
completely new to the database rather than to propositions that have been
changed. In other words, something can become known by the database, and
something that is already known can change. The distinction is subtle, I
know, but necessary--especially in a temporal database, but also in one that
only requires that transitions be constrained.

Brian Selzer wrote:
Nope. Just a value. Same as an int.


There are plenty of useful general purpose programming languages
that don't have any concept of identity in them. Mercury, for
example. (And in the non-general-purpose category, SQL.)
So I don't see how you could describe the concept as "necessary."
Useful, arguable, but not necessary. A turing machine doesn't
have any notion of identity. The lamba calculus has no notion
of identity. Come to that, the lambda calculus has no concept
of equality, either. Huh. So I guess neither one is necessary.

I'm not sure we're using the terms in the same way, though.
Do you speak Java?

Integer i = new Integer(1);
Integer j = new Integer(1);
System.out.println(i==j); // tests for identity
System.out.println(i.equals(j)); // tests for equality

Is that how you're using the terms?

In Java, == on a reference type tests for reference equality,
which is to say identity. If there were no reference types,
as in Prolog or SQL or whatever, then there is no identity.


One distinguishes between values by equality. If two values
are equal, they are the same value. If they are not equal,
they are not the same value. This is true for key values as
well as nonkey values.

Keys work because one can compare values, not because
one can compare identies. That is the fundamental difference
between keys and pointers.

Members of a set don't have identity.


Sure. This requires only values and equality.


Um, I don't see how it does. If you want to impose specific semantics
on the data, then that might constain how you allow the data to be
updated. But that is true of any constraint. Constraints are semantic
things; values are logical things. 240 is a perfectly legal int, but it
might not be an allowed age for a person.


I don't see why this should be so. Perhaps I'm just not following your
terminology. And anyway, if your domain wants keys that don't change,
just apply a constraint that enforces that.


I don't see how you can use the word "limitation" to describe
what you appear to consider the ability to update too much.
Assuming you add code to reject these updates you don't
like, would you say that you had "removed a limitation"?

Also, I think you somewhat overstate the case. If I have
a relation of customers with customerid in the range 1 - 1000,
and I decide I want customer ids to start at 1,000,000, I can
"UPDATE Customers set CustomerId = CustomerId + 1000000;"
and there's an update that changes keys and has
cardinality greater than one, and I can still determine
which tuple in the new relation value corresponds to any
given tuple in the original relation value.

If you want a system that supports identity, you don't want to
be using set theory. There are plenty to choose from, and
they are well-supported and popular!


It's not obvious to me.


If what you're saying here is "every relation must have at least one
key"
then I agree. If that's not what you're saying, then I don't
understand.


In this and in the previous part, it appears you are using the term
"identity value" as a synonym for key. Is that correct?


Perhaps an example is in order.


Marshall

"mAsterdam" <mAsterdam (AT) vrijdag (DOT) org> wrote

In other words, an onion and mushroom pizza is different from a mushroom and
onion pizza.

Here we go again.