One-To-One Relationships

#**161**

vldm10 wrote:

[...]

Quote:

I tried to explain my answer through an example. But it is not so
important. By the way, you can find the good answer on your question
"Why by only one attribute? Why not by a set of attributes? " on my
website www.dbdesign10.com look under the following: "7.1
Identifying the Plurality"

If I understand correctly, you propose to turn every
relation in your database into an entity by providing it with a
surrogate key, unless it already has a single-attribute key.

Section 7.1 states *how* to do this. It does *not* state why.

This is rather common (judging from the database designs I have seen.)
It effectively turns the model into an OO class model.

It has advantages (single-attribute references, uniformity),
but also disadvantages (read this group). What are your
arguments for doing it?

Quote:

Vladimir Odrljin

--
Reinier

#**162**

JOG wrote:

[...]

Quote:

What I meant to say was:
an entity is a relationship except that an entity is identifiable in itself,
while a relationship is identified by its (possibly entity-valued)
attribute values. But I already said that in my previous post.
By "identifiable" I mean "mentionable", "referrable".

I still think if you examine this again you'll see it really
struggles. 'What does identifiable in itself' mean?

By "identifiable" I mean "mentionable", "referrable".
"Can be used as an attribute value."

In other words, I propose what is sometimes called
an "object-oriented data model".

Quote:

We can only ever
identify things from observable attributes (and refer to them by
attributes too!).

Certainly, but we don't always make those attributes explicit.
And we don't always know what the relevant identifying attributes are.
More importantly, idenification and entities are relative; they vary
with context.

For instance, I write under the hypothesis that you are a person,
identifiable here as "JOG". But this assumption may be false: you may
be writing under several different names, and "JOG" may be used by more
than one person. Outside of this newsgroup I have no idea how to identify
the person(s) writing here as JOG.

I could remedy this by attempting to find more identifying information
(posting headers, newsgroup history, whatever). But I don't. I have
no need to. Assuming a newsgroup writer "JOG" works fine for me for now.
Should I ever want to, let's say, meet you on IRC or over coffee, I'd need
to extend my model of you, and provide a more detailed identification.

The question is whether I want to impose in my modelling language
the need to restructure the relationship between postings and authors
as soon as I make such more detailed identifications of persons.

[...]

Quote:

The question is not how entities are referred to in statements,
but how to model the meaning of those statements. Let's take the
"head of department" example again. Clearly when we obtain the
information who is head of which department, the statement giving us
this information will usually address the two relevant entities by name:
e.g. when I read that Ms Rice is the head of the USA's Foreign Affairs
department, I see two entities referred to by name.

There's the mistake imo. You have preassumed a conclusion - that
entities are there

Nope. My entities are constructs in my model. I construct them myself.
They do refer to things in the real world, but in a way my model doesn't
fully describe.

Quote:

I certainly see no entities in that statement at all. I see words. In
fact I can guarantee the existence of those words, but I certainly
can't metaphysical 'entities'. I can also see some words in the
statement describe roles and some that describe values. Some roles
aren't there so I resolve them in my noggin by context (e.g. Ms and
capitals indicates the start of a name for example.)

Just roles and values, a logical layer, on which I can impose all
sorts of conceptual models.

Please describe how you describe that persons are heads of departments
in a way that doesn't predetermine how I'm going to identify persons
and departments from now on. Or is it Just Wrong to want that? Why?

Quote:

Does that mean
we should express the meaning of that statement, the "head of department"
relationship, as one between department names and person names?

Why not? Its just data. Whatever conceptual model we want to conjure
in our heads afterwards is our own business.

Nope. We don't decide whether people change their names,
the personnel administration does (where I work, at least).
We don't want an administration with headless departments
as a side effect of name changes.

Quote:

No, it doesn't, which becomes evident as soon as persons or departments
change their names.

I 100% disagree, but now your getting into well trodden ground. If a
person changes their name are they then a different person? You are
saying no, but you are wrong because the actual answer is... It
depends! There's just no correct response.

Sure, we can't predict or anticipate every need for change in advance.
Still, I think this particular case is pretty clear.

Quote:

If you think this is
madness and that obviously we'd still be talking about the same
person, I refer you back to the question "are you the same person as
when you were 5", or my example about Harry Potter books. Context is
everything.

I am not trying to make claims about "what a real person really is".
I don't believe in references into "the real world". All we can do
is refer within models, or cross-refer from one model to another.

[...]

Quote:

My conclusion is that "head of" is a *reference* to the person entity,
and that we need entities (or references) as first-class citizens in
order to correctly express the meaning of this statement.
[...]

You recognize two items as the same thing in the real world,

Nope. I know other participants in this thread use the term "entity"
in that way, but I don't. I recognize them as the same *in my model*.

I should have probably explained that better ...

Quote:

by some consistent attribute (or set thereof).

The whole point of this discussion is that sometimes
you do not have or want a consistent attribute to pick.

Quote:

Pick the right ones, otherwise
your database will break.

Sure, in a database all tuples ultimately need to be identifiable in
terms of user-visible attributes, to avoid the existence of multiple
equivalent tuples. But even there, "the right ones" are not in general
a unique choice. E.g. depending on where I come I can identify myself
by my passport and/or my driver's license. Sometimes the identification
chosen depends on what information is practical or legal to maintain.

Quote:

You highlight flaws in a designers schema,
not problems in an underlying model.

?? Which model is on top of which?

Quote:

And don't underestimate how much
context resolving we do in our heads, and the amount of semantic
knowledge we apply to fix ambiguity and inconsistency.

You appear to underestimate how much *flexibility* we have
in all this context resolution business.

--
Reinier

#**163**

On Dec 6, 5:30 pm, rp... (AT) pcwin518 (DOT) campus.tue.nl (rpost) wrote:

Quote:

JOG wrote:

[...]

What I meant to say was:
an entity is a relationship except that an entity is identifiable in itself,
while a relationship is identified by its (possibly entity-valued)
attribute values. But I already said that in my previous post.
By "identifiable" I mean "mentionable", "referrable".

I still think if you examine this again you'll see it really
struggles. 'What does identifiable in itself' mean?

By "identifiable" I mean "mentionable", "referrable".
"Can be used as an attribute value."

I already addressed that. To refer to something you have to identify
it.

Quote:

In other words, I propose what is sometimes called
an "object-oriented data model".

Ugh, that's even worse than a logical model based on ERM. Ah yes the
OO-data model, the very one that died on its ass because it was a
nightmare to query, nevermind the fact it was a retro-grade
reinvention of the network model that was superceded 30 years ago.

Its like reinventing a square wheel.

Quote:

We can only ever
identify things from observable attributes (and refer to them by
attributes too!).

Certainly, but we don't always make those attributes explicit.

Yes we do. Always.

Quote:

And we don't always know what the relevant identifying attributes are.

Yes we do, otherwise we can't identify them in the real world.

Quote:

More importantly, idenification and entities are relative; they vary
with context.

For instance, I write under the hypothesis that you are a person,
identifiable here as "JOG". But this assumption may be false: you may
be writing under several different names, and "JOG" may be used by more
than one person. Outside of this newsgroup I have no idea how to identify
the person(s) writing here as JOG.

As far as you're concerned I am JOG. That's the entity you are dealing
with, and that's all there is. Nothing else. It doesn't matter what's
happening behind the curtain.

Quote:

I could remedy this by attempting to find more identifying information
(posting headers, newsgroup history, whatever). But I don't. I have
no need to. Assuming a newsgroup writer "JOG" works fine for me for now.

Why would you need to remedy it? What's wrong with it as it is? This
is a nonsensical discussion.

Quote:

Should I ever want to, let's say, meet you on IRC or over coffee, I'd need
to extend my model of you, and provide a more detailed identification.

Nope, then you'd be dealing with a different entity.

Quote:

The question is whether I want to impose in my modelling language
the need to restructure the relationship between postings and authors
as soon as I make such more detailed identifications of persons.

[...]

The question is not how entities are referred to in statements,
but how to model the meaning of those statements. Let's take the
"head of department" example again. Clearly when we obtain the
information who is head of which department, the statement giving us
this information will usually address the two relevant entities by name:
e.g. when I read that Ms Rice is the head of the USA's Foreign Affairs
department, I see two entities referred to by name.

There's the mistake imo. You have preassumed a conclusion - that
entities are there

Nope. My entities are constructs in my model. I construct them myself.
They do refer to things in the real world, but in a way my model doesn't
fully describe.

A great load of use that's going to be when something happens in the
real world that you need to update then.

Quote:

I certainly see no entities in that statement at all. I see words. In
fact I can guarantee the existence of those words, but I certainly
can't metaphysical 'entities'. I can also see some words in the
statement describe roles and some that describe values. Some roles
aren't there so I resolve them in my noggin by context (e.g. Ms and
capitals indicates the start of a name for example.)

Just roles and values, a logical layer, on which I can impose all
sorts of conceptual models.

Please describe how you describe that persons are heads of departments
in a way that doesn't predetermine how I'm going to identify persons
and departments from now on. Or is it Just Wrong to want that? Why?

Well not just wrong, but nonsensical. How can you describe something
if you can't identify it? C'mon Reinier!

Quote:

Does that mean
we should express the meaning of that statement, the "head of department"
relationship, as one between department names and person names?

Why not? Its just data. Whatever conceptual model we want to conjure
in our heads afterwards is our own business.

Nope. We don't decide whether people change their names,
the personnel administration does (where I work, at least).
We don't want an administration with headless departments
as a side effect of name changes.

I'm afraid you've missed the point. I've given you examples but I'm
not sure you have digested them properly mate.

Quote:

No, it doesn't, which becomes evident as soon as persons or departments
change their names.

I 100% disagree, but now your getting into well trodden ground. If a
person changes their name are they then a different person? You are
saying no, but you are wrong because the actual answer is... It
depends! There's just no correct response.

Sure, we can't predict or anticipate every need for change in advance.
Still, I think this particular case is pretty clear.

If you think this is
madness and that obviously we'd still be talking about the same
person, I refer you back to the question "are you the same person as
when you were 5", or my example about Harry Potter books. Context is
everything.

I am not trying to make claims about "what a real person really is".
I don't believe in references into "the real world". All we can do
is refer within models, or cross-refer from one model to another.

No, all our information comes from the real world. Start there, and
think how you identify things. If you want to fall internally into
your own model as an excuse for the lack of clarity, well your going
to have to accept at somepoint something will happen in the real world
and your database will break.

I'm sorry but I've given up with the rest because there is just no
clarity in the argumentation, and its such a long post now.

I can only reccommend you go off and read all the arguments against
the disaster that has been OO-DBMS.

Quote:

[...]

My conclusion is that "head of" is a *reference* to the person entity,
and that we need entities (or references) as first-class citizens in
order to correctly express the meaning of this statement.
[...]

You recognize two items as the same thing in the real world,

Nope. I know other participants in this thread use the term "entity"
in that way, but I don't. I recognize them as the same *in my model*.

I should have probably explained that better ...

by some consistent attribute (or set thereof).

The whole point of this discussion is that sometimes
you do not have or want a consistent attribute to pick.

Pick the right ones, otherwise
your database will break.

Sure, in a database all tuples ultimately need to be identifiable in
terms of user-visible attributes, to avoid the existence of multiple
equivalent tuples. But even there, "the right ones" are not in general
a unique choice. E.g. depending on where I come I can identify myself
by my passport and/or my driver's license. Sometimes the identification
chosen depends on what information is practical or legal to maintain.

You highlight flaws in a designers schema,
not problems in an underlying model.

?? Which model is on top of which?

And don't underestimate how much
context resolving we do in our heads, and the amount of semantic
knowledge we apply to fix ambiguity and inconsistency.

You appear to underestimate how much *flexibility* we have
in all this context resolution business.

--
Reinier

#**164**

JOG wrote:

Quote:

[...] Ugh, that's even worse than a logical model based on ERM. Ah yes the
OO-data model, the very one that died on its ass because it was a
nightmare to query,

Duh. Of course it isn't easy to query; that's what relational models
are for. It's a compromise. But it supports relational models.

Quote:

nevermind the fact it was a retro-grade
reinvention of the network model that was superceded 30 years ago.

The network model didn't have query at all, as far as I recall.

Quote:

We can only ever
identify things from observable attributes (and refer to them by
attributes too!).

Certainly, but we don't always make those attributes explicit.

Yes we do. Always.

Not in my experience.

Quote:

And we don't always know what the relevant identifying attributes are.

Yes we do, otherwise we can't identify them in the real world.

You mean, assuming that we can identify them consistently throughout
the lifetime of the model. This is getting repetitive.

[...]

Quote:

Should I ever want to, let's say, meet you on IRC or over coffee, I'd need
to extend my model of you, and provide a more detailed identification.

Nope, then you'd be dealing with a different entity.

It depends on who you ask.

[...]

Quote:

Please describe how you describe that persons are heads of departments
in a way that doesn't predetermine how I'm going to identify persons
and departments from now on. Or is it Just Wrong to want that? Why?

Well not just wrong, but nonsensical. How can you describe something
if you can't identify it? C'mon Reinier!

I didn't say I can't identify it. I'm just saying I may not yet have
determined how to identify it, or that I want to identify it differently
tomorrow. This is getting repetitive.

Quote:

Does that mean
we should express the meaning of that statement, the "head of department"
relationship, as one between department names and person names?

Why not? Its just data. Whatever conceptual model we want to conjure
in our heads afterwards is our own business.

Nope. We don't decide whether people change their names,
the personnel administration does (where I work, at least).
We don't want an administration with headless departments
as a side effect of name changes.

I'm afraid you've missed the point. I've given you examples but I'm
not sure you have digested them properly mate.

The feeling is mutual. This is getting repetitive.
Thanks for the effort anyway; I still learnt some things.

[...]

Quote:

I can only reccommend you go off and read all the arguments against
the disaster that has been OO-DBMS.

Where?

--
Reinier

#**165**

On Dec 6, 8:12 pm, rp... (AT) pcwin518 (DOT) campus.tue.nl (rpost) wrote:

Quote:

JOG wrote:
[...] Ugh, that's even worse than a logical model based on ERM. Ah yes the
OO-data model, the very one that died on its ass because it was a
nightmare to query,

Duh. Of course it isn't easy to query; that's what relational models
are for. It's a compromise.

How is it a compromise? OO-DBMS give you nothing extra, and make
querying harder. That's why the market for them failed.

Quote:

But it supports relational models.

nevermind the fact it was a retro-grade
reinvention of the network model that was superceded 30 years ago.

The network model didn't have query at all, as far as I recall.

We can only ever
identify things from observable attributes (and refer to them by
attributes too!).

Certainly, but we don't always make those attributes explicit.

Yes we do. Always.

Not in my experience.

Then do you get sent messages from an omnipotent higher being to tell
you the identity of something!

I simply cannot think of any example
of how something is identified without using explicit, identifying
attributes!

Quote:

And we don't always know what the relevant identifying attributes are.

Yes we do, otherwise we can't identify them in the real world.

You mean, assuming that we can identify them consistently throughout
the lifetime of the model. This is getting repetitive.

You don't need to assume that, its an absolute necessity. Otherwise
you end up with a broken database. But I understand that your not
seeing the practical issues of what I am saying, so maybe we should
give up. I'm just trying to help you out - I get nothing myself out of
these discussions!

Quote:

[...]

Should I ever want to, let's say, meet you on IRC or over coffee, I'd need
to extend my model of you, and provide a more detailed identification.

Nope, then you'd be dealing with a different entity.

It depends on who you ask.

?

Quote:

[...]

Please describe how you describe that persons are heads of departments
in a way that doesn't predetermine how I'm going to identify persons
and departments from now on. Or is it Just Wrong to want that? Why?

Well not just wrong, but nonsensical. How can you describe something
if you can't identify it? C'mon Reinier!

I didn't say I can't identify it. I'm just saying I may not yet have
determined how to identify it, or that I want to identify it differently
tomorrow. This is getting repetitive.

If its identifying attributes are different tomorrow its a different
thing! An identifying attribute cannot change, because it is used to
distinguish an item from others, over its whole lifetime.

I think perhaps you have a different notion of what identification is.

Quote:

Does that mean
we should express the meaning of that statement, the "head of department"
relationship, as one between department names and person names?

Why not? Its just data. Whatever conceptual model we want to conjure
in our heads afterwards is our own business.

Nope. We don't decide whether people change their names,
the personnel administration does (where I work, at least).
We don't want an administration with headless departments
as a side effect of name changes.

I'm afraid you've missed the point. I've given you examples but I'm
not sure you have digested them properly mate.

The feeling is mutual. This is getting repetitive.

I promise you I have been through these arguments before - In fact I'd
say I didn't really understand the real advances that Codd made before
I arrived at cdt, and got a free fast-track education. But gradually
(and sometimes painfully) people a lot more knowledgeable than myself
have helped clarify my thoughts, and now the logic seems to all fit.

OID's bad. Content based addressing good. Understanding that entities
don't exist outside of their attributes, good (that was a painful one
as I recall). Recognizing that identifying attributes cannot change,
check. Understanding the impact that object containment has on
querying and bias, also check. etc.

Perhaps you have not succinctly described what your actual point is
due to the tit-for-tat responses that usenet debate engenders. Stating
your whole point succinctly in 4 or 5 lines always helps.

Quote:

Thanks for the effort anyway; I still learnt some things.

Well I appreciate you saying that. Best of luck to you Reinier.

Quote:

[...]

I can only reccommend you go off and read all the arguments against
the disaster that has been OO-DBMS.

Where?

Date, while I don't agree with some of the things he says, has written
dozens of articles illustrating why db's based on OID's are
deleterious. Pascal and Darwen have also published on the arguments
against.

Even if I can't convince you of anything, most of the articles in
"relational database writings" are a good read.

Regards, J.

Quote:

--
Reinier

#**166**

On Dec 5, 7:09 pm, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

Quote:

On 5 dec, 15:45, vldm10 <vld... (AT) yahoo (DOT) com> wrote:

On Dec 4, 5:20 pm, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

On 4 dec, 21:55, vldm10 <vld... (AT) yahoo (DOT) com> wrote:

On Dec 3, 6:01 am, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

On 2 dec, 18:53, vldm10 <vld... (AT) yahoo (DOT) com> wrote:

On Dec 2, 4:36 am, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

On 1 dec, 06:26, vldm10 <vld... (AT) yahoo (DOT) com> wrote:

On Nov 30, 9:34 am, Jan Hidders <hidd... (AT) gmail (DOT) com> wrote:

Why by only one attribute? Why not by a set of attributes? Or a
combination of attributes and relationships (as is the case for weak
entities)?

This is OK, but my advice to you -don't use it often.
I will give you one example:
The relation has A1, A2, A3, A4 "attributes" and they are mutually
independent (i.e. they are in BCNF)
The "attributes" can change their values for "entity" like in
"temporal DB". User needs on line all information for any "entity" in
any moment.
Can you please write the key for this relation so that we can discuss
it.

You do realize we were talking about ER modeling, not RM modeling,
don't you?

Here in this tread it is about E/R and RM as well as relationship
among them and I also used terms "entity" and "attribute".

My remark that you responded to was only about ER modelling.

I tried to explain my answer through an example.

You formulated the explanation of your answer to an issue in ER
modeling in RM terminology. If you would have formulated it in ER
terminology that might have helped you considerably to make your
point. RIght now I still don't have a clue what you are trying to tell
me or even whether it is actually relevant for the question at hand.

-- Jan Hidders- Hide quoted text -

- Show quoted text -

Jim wrote "...... and identify them (entities) by one attribute..." and
you asked "why by only one attribute? Why not by a set of
attributes?"
My objection here is related to misunderstanding what is identifying?
What is construction to make entities to be distinct? What we use for
identifying? What is difference between "distinguishing" and
identifying? etc
On your question "Why not by a set of attributes?" we not identify an
entity I gave the answer: "This is OK, but my advice to you - don't
use it often."
To get clue I will gave you one example:

During a phone call, we would never say the following: "May I speak
with the 5 foot tall and has blue eyes and has brown hair and ..."
Rather, we will say: "May I speak with John?"

I wrote small theory about identifying and above example is from
there. I already recommended you to read it (if you are interested?)
You can find it on my website: www.dbdesign10.com
look under the following: "7.1 Identifying the Plurality"
I am not interested in further discussion about this.

*shrug* Suit yourself.

-- Jan Hidders- Hide quoted text -

- Show quoted text -

I must tell you that it is not possible to identify an entity by "a
set of attributes? Or a combination of attribute and relationship (as
is the case for weak entities)?
An entity by definition is an object in the real world while a set
isn't. An entity's attributes are "physical" while relational's
aren't. If you formulate properly your question, then it will be
possible to identify an entity by a set of attributes. Act of
identifying is specific.
You should be aware what it means to identify an entity which has
about 10 attributes on terabyte population. Not to mention identifying
with "Temporal DB" or with transfer of data from one environment to
another
You can notice that 99.99% of DBs are with one column key.

Vladimir Odrljin

#**167**

On Dec 6, 11:15 am, rp... (AT) pcwin518 (DOT) campus.tue.nl (rpost) wrote:

Quote:

If I understand correctly

I am sorry but you completely misunderstand my solution.
It seems like you read my solution from back to begging instead
from the begging to back.

Quote:

you propose to turn every relation in your database into an
entity

No I propose opposite: from an entity to a relation.

--
Reinier

Vladimir Odrljin

#**168**

JOG wrote:

Quote:

We can only ever
identify things from observable attributes (and refer to them by
attributes too!).

Certainly, but we don't always make those attributes explicit.

Yes we do. Always.

Not in my experience.

Then do you get sent messages from an omnipotent higher being to tell
you the identity of something!

I simply cannot think of any example
of how something is identified without using explicit, identifying
attributes!

Yes, you can. Suppose, one morning I feel really ill, so I pick up the
phone, call our secretary and say: "Hello <name>, I'm not coming today,
I'm going to have to stay in bed." As a result of this phone call, an
update is issued on the employee database, to register my absence due
to illness on this day. The secretary has identified me by my voice,
not by anything the database registers about me.

But of course I also have to identify the tuples in the database
relevant to this update. This identification must ultimately rely
on externally observable information that is observably associated
with me (my name, employee number, whatever). But that identification
may not be direct: it can rely on the use of internal references
(surrogates, oids).

I notice the discussion has progressed elsewhere so I won't continue here.

--
Reinier

#**169**

On Dec 20, 7:40 pm, rp... (AT) pcwin518 (DOT) campus.tue.nl (rpost) wrote:

Quote:

JOG wrote:
We can only ever
identify things from observable attributes (and refer to them by
attributes too!).

Certainly, but we don't always make those attributes explicit.

Yes we do. Always.

Not in my experience.

Then do you get sent messages from an omnipotent higher being to tell
you the identity of something!

I simply cannot think of any example
of how something is identified without using explicit, identifying
attributes!

Yes, you can. Suppose, one morning I feel really ill, so I pick up the
phone, call our secretary and say: "Hello <name>, I'm not coming today,
I'm going to have to stay in bed." As a result of this phone call, an
update is issued on the employee database, to register my absence due
to illness on this day. The secretary has identified me by my voice,
not by anything the database registers about me.

Lucky that you didn't have a throat infection I guess. Or that you
weren't talking to someone you hadn't seen for ten years (given that
voices change). But then, in the context of your example I guess a
voice is an explicit identifying attribute. Er, hold on... that's
exactly what I said you'd need to use to identify an entity

And then your secretary identifies the construct you correspond to in
the db by what? An OID? Course not.

Quote:

But of course I also have to identify the tuples in the database
relevant to this update. This identification must ultimately rely
on externally observable information that is observably associated
with me (my name, employee number, whatever).

That's exactly what I have been saying. Hell, at least we're agreed
there. One has to correspond internal and external entities somehow.
It's just your reliance on mutable attributes that won't /generalize/.

Quote:

But that identification may not be direct: it can rely on the use of internal references
(surrogates, oids).

Ok, I'll give it one last spin - I really hope that you give this a
real think through, because I am sure it's right Reinier...

Yes /sometimes/ it is possible that items might be able to be
identified indirectly - but only in specific applications and
situation (people are great at this, we know our history and the
context of any situation we're in, and that's probably why all your
examples involve people, and not inanimate objects). But this indirect
method is not /always/ possible, and that's the key point. We do want
a generalized data model after all.

What would happen if every 'indirect' identifier (as you put it) of an
entity has changed. Such a situation is perfectly possible, otherwise
those attributes would have been 'direct' identifiers. And consider
further that the entity in question (an inanimate object say) cannot
relay its history to you? No indirect identification possible any
more. Because of this we need just one thing that stays consistent.
And that one consistent attribute can't be hidden like a surrogate or
an OID, because it must be recognizable from the external entity (as I
think we've agreed on I think).

A WINTER'S TALE OF OID's...
"Its me. I'm ill. Not coming in for work"
"Who? I can't recognize your voice, because of your cold"
"Sarah who works in finance"
"Look, we have 5 people could Sarah in finance, so that's no help I'm
afraid. "
"I have died red hair?"
"None are on record with red hair."
"Agh, I change it all the time. Fashion, eh"
"What car do you drive? I can tally with that maybe"
"A Porsche"
"Hmmm, No Sarah's with Porches here. Are you sure?"
"Well its pretty new. Not on the system yet I guess."
"What was your old car then?"
"Er... I'm not sure now. It was er... blue? I can't really remember.
Japanese thing I think..."
"Brilliant. Look, why don't you just tell me your OID please and I can
update you as ill on the db"
"My what?"
"Your OID - your secret hidden number"
"I have no idea what you are talking about. This is getting ridiculous
- can't I just tell you my bloody employee ID"
"No I'm sorry, Reinier fixed up our systems up last week and replaced
them with these hidden OID things"
"The one that's kept secret from me?"
"Yup, that's the one"
"Forget it. I'm going back to bed."

Quote:

I notice the discussion has progressed elsewhere so I won't continue here.

--
Reinier