Re: what are keys and surrogates?

On Jan 6, 11:18 pm, rp..._at_pcwin518.campus.tue.nl (rpost) wrote:
> [tired snippage]

Look, I can ignore the random redefinitions of terms, the lack of focussed argumentation and even the abrasive tone of the posts (noone initially likes someone pointing out they might be wrong after all). All I really care about is the damage to db research that hidden attributes and OID's can have, and as such perhaps you can address this brutally simple example?

We have some bits of paper with numbers written on (in pencil). We are storing info about these bits of paper in a database using the schema: {paperID, Value}. The key, PaperID, is a unique database generated hidden surrogate.

We have an enumeration:
{ (paperID:1, Value:X), (paperID:2, Value:Y), (paperID:3, Value:Z) }

Someone comes to you the DB admin, with 3 bits of paper and says, ok the boss has changed the values on some of the bits of paper. What I have here is one bit of paper with an A on, one with a B and and one with a Z. Please update the database accordingly.

Please tell me what you do to deal with this. No redefinitions, or tangents, just tell me how you ensure that the right PaperID's get the right updates? How do you known which paperID has changed, and to which value? How do you even know you have been presented with the same bits of paper as the initial three, and not new ones altogether? The DBA would be at a complete loss.

 If you do follow this example, then perhaps you could explain why you are having trouble generalizing it to any schema where the key attribute is hidden (i.e. non-visible to the business), and all other attributes are mutable. Received on Tue Jan 08 2008 - 01:26:38 CET