 | |
#1281
 
| ||||||||||
| ||||||||||
|
Re: what are keys and surrogates? -
02-17-2008
, 06:55 PM
|
JOG wrote: Why on earth can't people be identified inside the database by their name, and parent's name, if that works outside? It doesn't. I thought we already agreed on that. It's the whole point of this example that it doesn't. |
lineage.
2) I respond by saying fine, then use lineage to identify them in the
database.
3) You say you can't, because it doesn't work in the real
world.....even though your example was of lineage being the only thing
that you could use in the real world.
Doesn't that seem just a little bit of a weird argument?
Quote:
|
If you don't find the example convincing, you'll have to come up with something other than trying to bend it into something else. If you are saying that its because two people may have the same name and the same Parent_name, of course yes that would break things, but it would / equally/ stump you in real life too. And in real life, this is sometimes resolved by using chains of names, *as the example shows*. Which, in turn, shows that the people involve work with an underlying data model that contains person references. That is the whole point of the example. |
All it just shows that people can be identified by the "names" of
their ancestors, which we've seen can happily be viewed as just more
attribute values.
Do you think there's a difference between attributes and relationships
that is anything but arbitrary?
Quote:
|
If you don't find the example convincing, fine. If you choose not to understand it, fine. But stop trying to bend it into something else. So to deal with it in real life you might specify the Grandparent's name too. And if that were the same, then the Great-GrandParent as well. If that gives you the way to identify the person uniquely, excellent - you now know if you ever need to build a database for the info, you can use a table with a PK(Name, P, GP, GPP). If not, just keep on going with those ancestors. No OID's necessary. Except that 1) there is no fixed limit on the length of the chain. |
identify someone varies from person to person. well, yup, that would
no doubt be correct. I don't see any problem there to identification
and FOL. Is that an issue you have with RM or content based
addressing?
Quote:
|
2) you'll end up with an awful lot of NULLs on those tables |
issue. In fact, when we agree we don't /need/ OID's for
identification, and no doubt go on to talk about whether there are
practical reasons why they might be useful, that'd probably come up.
Quote:
|
If that's not enough and you need grandparents to distinguish them, then use that too, and so on. Just work out how you identify something in real life and then use that in the database. Yes, that's exactly what I've been doing here. No, I meant if you use someone's ancestors to identify them in real life, then that's exactly what you should use to identify them in a tuple. No, you're asking for something much stronger: that we have a fixed-format formula for identifying any person, and that the same person is always identified with the same parameters to that formula. |
because I'm not saying that.
Quote:
|
A strong requirement; sensible, too, at least for relational databases; and one this example doesn't meet. Who said that the same person will always be identified by the same fixed path? WHo said that the paths for different persons will always be of the same length? I stated neither. It seems very unlikely. |
understand why you'd think that, because it might seem like i'm
championing RM tables, but I'm not. All I am promoting is the logic of
using /content-based addressing/. It's what we use in the outside
world and should be a central component of any future 'ultimate data
model (TM)'. Hey, maybe you'll even invent it once we get this OID
stuff out your system? ;P
Quote:
|
I'm baffled why you'd think you'd corresponded to real life at all by inventing invisible numbers. They are *not* numbers. And OIDs are just a way to implement references in terms of a flat relational model. Conceptually, what we have is tuple references. |
too. Feels a bit silly now).
Quote:
|
There are no OID's in the bible. And your example showed people being successfully referred to by their parent, grandparent, etc, so its absolutely clear we don't need anything else to identify them. You're doing it again: confusing, in your wording, "parent" and "grandparent" with "the parent's name" and "the grandparent's name". |
it would be obvious I was talking about their names, given that's what
your example is about.
Interesting parallel question - would it scare you if 'you' were only
made up of values and had no magic OID number acting as a substrate,
no essential bit that was 'you'? I like not to think about it meself.
Bhuddism has the notion as a central tenet, and while I know they're
probably right, it always suprises me they are so chilled about it all
and not running around panicking. I always find OID's to be a related
topic...
Quote:
|
In fact the example is a cracker - I can use it in the future not only to explain why we don't need OID's, but also to show that identifiers can get very long, and that's why we make up things like SSN's to make life easier. Absolutely. Life in biblical times would have been much easier if every Joshua had worn a chip on his shoulder. |
Quote:
|
-- Reinier |
#1282
| ||||||||||
| ||||||||||
|
|
JOG wrote: Why on earth can't people be identified inside the database by their name, and parent's name, if that works outside? It doesn't. I thought we already agreed on that. It's the whole point of this example that it doesn't. |
lineage.
2) I respond by saying fine, then use lineage to identify them in the
database.
3) You say you can't, because it doesn't work in the real
world.....even though your example was of lineage being the only thing
that you could use in the real world.
Doesn't that seem just a little bit of a weird argument?
Quote:
|
If you don't find the example convincing, you'll have to come up with something other than trying to bend it into something else. If you are saying that its because two people may have the same name and the same Parent_name, of course yes that would break things, but it would / equally/ stump you in real life too. And in real life, this is sometimes resolved by using chains of names, *as the example shows*. Which, in turn, shows that the people involve work with an underlying data model that contains person references. That is the whole point of the example. |
All it just shows that people can be identified by the "names" of
their ancestors, which we've seen can happily be viewed as just more
attribute values.
Do you think there's a difference between attributes and relationships
that is anything but arbitrary?
Quote:
|
If you don't find the example convincing, fine. If you choose not to understand it, fine. But stop trying to bend it into something else. So to deal with it in real life you might specify the Grandparent's name too. And if that were the same, then the Great-GrandParent as well. If that gives you the way to identify the person uniquely, excellent - you now know if you ever need to build a database for the info, you can use a table with a PK(Name, P, GP, GPP). If not, just keep on going with those ancestors. No OID's necessary. Except that 1) there is no fixed limit on the length of the chain. |
identify someone varies from person to person. well, yup, that would
no doubt be correct. I don't see any problem there to identification
and FOL. Is that an issue you have with RM or content based
addressing?
Quote:
|
2) you'll end up with an awful lot of NULLs on those tables |
issue. In fact, when we agree we don't /need/ OID's for
identification, and no doubt go on to talk about whether there are
practical reasons why they might be useful, that'd probably come up.
Quote:
|
If that's not enough and you need grandparents to distinguish them, then use that too, and so on. Just work out how you identify something in real life and then use that in the database. Yes, that's exactly what I've been doing here. No, I meant if you use someone's ancestors to identify them in real life, then that's exactly what you should use to identify them in a tuple. No, you're asking for something much stronger: that we have a fixed-format formula for identifying any person, and that the same person is always identified with the same parameters to that formula. |
because I'm not saying that.
Quote:
|
A strong requirement; sensible, too, at least for relational databases; and one this example doesn't meet. Who said that the same person will always be identified by the same fixed path? WHo said that the paths for different persons will always be of the same length? I stated neither. It seems very unlikely. |
understand why you'd think that, because it might seem like i'm
championing RM tables, but I'm not. All I am promoting is the logic of
using /content-based addressing/. It's what we use in the outside
world and should be a central component of any future 'ultimate data
model (TM)'. Hey, maybe you'll even invent it once we get this OID
stuff out your system? ;P
Quote:
|
I'm baffled why you'd think you'd corresponded to real life at all by inventing invisible numbers. They are *not* numbers. And OIDs are just a way to implement references in terms of a flat relational model. Conceptually, what we have is tuple references. |
too. Feels a bit silly now).
Quote:
|
There are no OID's in the bible. And your example showed people being successfully referred to by their parent, grandparent, etc, so its absolutely clear we don't need anything else to identify them. You're doing it again: confusing, in your wording, "parent" and "grandparent" with "the parent's name" and "the grandparent's name". |
it would be obvious I was talking about their names, given that's what
your example is about.
Interesting parallel question - would it scare you if 'you' were only
made up of values and had no magic OID number acting as a substrate,
no essential bit that was 'you'? I like not to think about it meself.
Bhuddism has the notion as a central tenet, and while I know they're
probably right, it always suprises me they are so chilled about it all
and not running around panicking. I always find OID's to be a related
topic...
Quote:
|
In fact the example is a cracker - I can use it in the future not only to explain why we don't need OID's, but also to show that identifiers can get very long, and that's why we make up things like SSN's to make life easier. Absolutely. Life in biblical times would have been much easier if every Joshua had worn a chip on his shoulder. |
Quote:
|
-- Reinier |
#1283
| ||||||||||
| ||||||||||
|
|
JOG wrote: Why on earth can't people be identified inside the database by their name, and parent's name, if that works outside? It doesn't. I thought we already agreed on that. It's the whole point of this example that it doesn't. |
lineage.
2) I respond by saying fine, then use lineage to identify them in the
database.
3) You say you can't, because it doesn't work in the real
world.....even though your example was of lineage being the only thing
that you could use in the real world.
Doesn't that seem just a little bit of a weird argument?
Quote:
|
If you don't find the example convincing, you'll have to come up with something other than trying to bend it into something else. If you are saying that its because two people may have the same name and the same Parent_name, of course yes that would break things, but it would / equally/ stump you in real life too. And in real life, this is sometimes resolved by using chains of names, *as the example shows*. Which, in turn, shows that the people involve work with an underlying data model that contains person references. That is the whole point of the example. |
All it just shows that people can be identified by the "names" of
their ancestors, which we've seen can happily be viewed as just more
attribute values.
Do you think there's a difference between attributes and relationships
that is anything but arbitrary?
Quote:
|
If you don't find the example convincing, fine. If you choose not to understand it, fine. But stop trying to bend it into something else. So to deal with it in real life you might specify the Grandparent's name too. And if that were the same, then the Great-GrandParent as well. If that gives you the way to identify the person uniquely, excellent - you now know if you ever need to build a database for the info, you can use a table with a PK(Name, P, GP, GPP). If not, just keep on going with those ancestors. No OID's necessary. Except that 1) there is no fixed limit on the length of the chain. |
identify someone varies from person to person. well, yup, that would
no doubt be correct. I don't see any problem there to identification
and FOL. Is that an issue you have with RM or content based
addressing?
Quote:
|
2) you'll end up with an awful lot of NULLs on those tables |
issue. In fact, when we agree we don't /need/ OID's for
identification, and no doubt go on to talk about whether there are
practical reasons why they might be useful, that'd probably come up.
Quote:
|
If that's not enough and you need grandparents to distinguish them, then use that too, and so on. Just work out how you identify something in real life and then use that in the database. Yes, that's exactly what I've been doing here. No, I meant if you use someone's ancestors to identify them in real life, then that's exactly what you should use to identify them in a tuple. No, you're asking for something much stronger: that we have a fixed-format formula for identifying any person, and that the same person is always identified with the same parameters to that formula. |
because I'm not saying that.
Quote:
|
A strong requirement; sensible, too, at least for relational databases; and one this example doesn't meet. Who said that the same person will always be identified by the same fixed path? WHo said that the paths for different persons will always be of the same length? I stated neither. It seems very unlikely. |
understand why you'd think that, because it might seem like i'm
championing RM tables, but I'm not. All I am promoting is the logic of
using /content-based addressing/. It's what we use in the outside
world and should be a central component of any future 'ultimate data
model (TM)'. Hey, maybe you'll even invent it once we get this OID
stuff out your system? ;P
Quote:
|
I'm baffled why you'd think you'd corresponded to real life at all by inventing invisible numbers. They are *not* numbers. And OIDs are just a way to implement references in terms of a flat relational model. Conceptually, what we have is tuple references. |
too. Feels a bit silly now).
Quote:
|
There are no OID's in the bible. And your example showed people being successfully referred to by their parent, grandparent, etc, so its absolutely clear we don't need anything else to identify them. You're doing it again: confusing, in your wording, "parent" and "grandparent" with "the parent's name" and "the grandparent's name". |
it would be obvious I was talking about their names, given that's what
your example is about.
Interesting parallel question - would it scare you if 'you' were only
made up of values and had no magic OID number acting as a substrate,
no essential bit that was 'you'? I like not to think about it meself.
Bhuddism has the notion as a central tenet, and while I know they're
probably right, it always suprises me they are so chilled about it all
and not running around panicking. I always find OID's to be a related
topic...
Quote:
|
In fact the example is a cracker - I can use it in the future not only to explain why we don't need OID's, but also to show that identifiers can get very long, and that's why we make up things like SSN's to make life easier. Absolutely. Life in biblical times would have been much easier if every Joshua had worn a chip on his shoulder. |
Quote:
|
-- Reinier |
#1284
| ||||||||||
| ||||||||||
|
|
JOG wrote: Why on earth can't people be identified inside the database by their name, and parent's name, if that works outside? It doesn't. I thought we already agreed on that. It's the whole point of this example that it doesn't. |
lineage.
2) I respond by saying fine, then use lineage to identify them in the
database.
3) You say you can't, because it doesn't work in the real
world.....even though your example was of lineage being the only thing
that you could use in the real world.
Doesn't that seem just a little bit of a weird argument?
Quote:
|
If you don't find the example convincing, you'll have to come up with something other than trying to bend it into something else. If you are saying that its because two people may have the same name and the same Parent_name, of course yes that would break things, but it would / equally/ stump you in real life too. And in real life, this is sometimes resolved by using chains of names, *as the example shows*. Which, in turn, shows that the people involve work with an underlying data model that contains person references. That is the whole point of the example. |
All it just shows that people can be identified by the "names" of
their ancestors, which we've seen can happily be viewed as just more
attribute values.
Do you think there's a difference between attributes and relationships
that is anything but arbitrary?
Quote:
|
If you don't find the example convincing, fine. If you choose not to understand it, fine. But stop trying to bend it into something else. So to deal with it in real life you might specify the Grandparent's name too. And if that were the same, then the Great-GrandParent as well. If that gives you the way to identify the person uniquely, excellent - you now know if you ever need to build a database for the info, you can use a table with a PK(Name, P, GP, GPP). If not, just keep on going with those ancestors. No OID's necessary. Except that 1) there is no fixed limit on the length of the chain. |
identify someone varies from person to person. well, yup, that would
no doubt be correct. I don't see any problem there to identification
and FOL. Is that an issue you have with RM or content based
addressing?
Quote:
|
2) you'll end up with an awful lot of NULLs on those tables |
issue. In fact, when we agree we don't /need/ OID's for
identification, and no doubt go on to talk about whether there are
practical reasons why they might be useful, that'd probably come up.
Quote:
|
If that's not enough and you need grandparents to distinguish them, then use that too, and so on. Just work out how you identify something in real life and then use that in the database. Yes, that's exactly what I've been doing here. No, I meant if you use someone's ancestors to identify them in real life, then that's exactly what you should use to identify them in a tuple. No, you're asking for something much stronger: that we have a fixed-format formula for identifying any person, and that the same person is always identified with the same parameters to that formula. |
because I'm not saying that.
Quote:
|
A strong requirement; sensible, too, at least for relational databases; and one this example doesn't meet. Who said that the same person will always be identified by the same fixed path? WHo said that the paths for different persons will always be of the same length? I stated neither. It seems very unlikely. |
understand why you'd think that, because it might seem like i'm
championing RM tables, but I'm not. All I am promoting is the logic of
using /content-based addressing/. It's what we use in the outside
world and should be a central component of any future 'ultimate data
model (TM)'. Hey, maybe you'll even invent it once we get this OID
stuff out your system? ;P
Quote:
|
I'm baffled why you'd think you'd corresponded to real life at all by inventing invisible numbers. They are *not* numbers. And OIDs are just a way to implement references in terms of a flat relational model. Conceptually, what we have is tuple references. |
too. Feels a bit silly now).
Quote:
|
There are no OID's in the bible. And your example showed people being successfully referred to by their parent, grandparent, etc, so its absolutely clear we don't need anything else to identify them. You're doing it again: confusing, in your wording, "parent" and "grandparent" with "the parent's name" and "the grandparent's name". |
it would be obvious I was talking about their names, given that's what
your example is about.
Interesting parallel question - would it scare you if 'you' were only
made up of values and had no magic OID number acting as a substrate,
no essential bit that was 'you'? I like not to think about it meself.
Bhuddism has the notion as a central tenet, and while I know they're
probably right, it always suprises me they are so chilled about it all
and not running around panicking. I always find OID's to be a related
topic...
Quote:
|
In fact the example is a cracker - I can use it in the future not only to explain why we don't need OID's, but also to show that identifiers can get very long, and that's why we make up things like SSN's to make life easier. Absolutely. Life in biblical times would have been much easier if every Joshua had worn a chip on his shoulder. |
Quote:
|
-- Reinier |
#1285
| ||||||||||
| ||||||||||
|
|
JOG wrote: Why on earth can't people be identified inside the database by their name, and parent's name, if that works outside? It doesn't. I thought we already agreed on that. It's the whole point of this example that it doesn't. |
lineage.
2) I respond by saying fine, then use lineage to identify them in the
database.
3) You say you can't, because it doesn't work in the real
world.....even though your example was of lineage being the only thing
that you could use in the real world.
Doesn't that seem just a little bit of a weird argument?
Quote:
|
If you don't find the example convincing, you'll have to come up with something other than trying to bend it into something else. If you are saying that its because two people may have the same name and the same Parent_name, of course yes that would break things, but it would / equally/ stump you in real life too. And in real life, this is sometimes resolved by using chains of names, *as the example shows*. Which, in turn, shows that the people involve work with an underlying data model that contains person references. That is the whole point of the example. |
All it just shows that people can be identified by the "names" of
their ancestors, which we've seen can happily be viewed as just more
attribute values.
Do you think there's a difference between attributes and relationships
that is anything but arbitrary?
Quote:
|
If you don't find the example convincing, fine. If you choose not to understand it, fine. But stop trying to bend it into something else. So to deal with it in real life you might specify the Grandparent's name too. And if that were the same, then the Great-GrandParent as well. If that gives you the way to identify the person uniquely, excellent - you now know if you ever need to build a database for the info, you can use a table with a PK(Name, P, GP, GPP). If not, just keep on going with those ancestors. No OID's necessary. Except that 1) there is no fixed limit on the length of the chain. |
identify someone varies from person to person. well, yup, that would
no doubt be correct. I don't see any problem there to identification
and FOL. Is that an issue you have with RM or content based
addressing?
Quote:
|
2) you'll end up with an awful lot of NULLs on those tables |
issue. In fact, when we agree we don't /need/ OID's for
identification, and no doubt go on to talk about whether there are
practical reasons why they might be useful, that'd probably come up.
Quote:
|
If that's not enough and you need grandparents to distinguish them, then use that too, and so on. Just work out how you identify something in real life and then use that in the database. Yes, that's exactly what I've been doing here. No, I meant if you use someone's ancestors to identify them in real life, then that's exactly what you should use to identify them in a tuple. No, you're asking for something much stronger: that we have a fixed-format formula for identifying any person, and that the same person is always identified with the same parameters to that formula. |
because I'm not saying that.
Quote:
|
A strong requirement; sensible, too, at least for relational databases; and one this example doesn't meet. Who said that the same person will always be identified by the same fixed path? WHo said that the paths for different persons will always be of the same length? I stated neither. It seems very unlikely. |
understand why you'd think that, because it might seem like i'm
championing RM tables, but I'm not. All I am promoting is the logic of
using /content-based addressing/. It's what we use in the outside
world and should be a central component of any future 'ultimate data
model (TM)'. Hey, maybe you'll even invent it once we get this OID
stuff out your system? ;P
Quote:
|
I'm baffled why you'd think you'd corresponded to real life at all by inventing invisible numbers. They are *not* numbers. And OIDs are just a way to implement references in terms of a flat relational model. Conceptually, what we have is tuple references. |
too. Feels a bit silly now).
Quote:
|
There are no OID's in the bible. And your example showed people being successfully referred to by their parent, grandparent, etc, so its absolutely clear we don't need anything else to identify them. You're doing it again: confusing, in your wording, "parent" and "grandparent" with "the parent's name" and "the grandparent's name". |
it would be obvious I was talking about their names, given that's what
your example is about.
Interesting parallel question - would it scare you if 'you' were only
made up of values and had no magic OID number acting as a substrate,
no essential bit that was 'you'? I like not to think about it meself.
Bhuddism has the notion as a central tenet, and while I know they're
probably right, it always suprises me they are so chilled about it all
and not running around panicking. I always find OID's to be a related
topic...
Quote:
|
In fact the example is a cracker - I can use it in the future not only to explain why we don't need OID's, but also to show that identifiers can get very long, and that's why we make up things like SSN's to make life easier. Absolutely. Life in biblical times would have been much easier if every Joshua had worn a chip on his shoulder. |
Quote:
|
-- Reinier |
#1286
| ||||||||||
| ||||||||||
|
|
JOG wrote: Why on earth can't people be identified inside the database by their name, and parent's name, if that works outside? It doesn't. I thought we already agreed on that. It's the whole point of this example that it doesn't. |
lineage.
2) I respond by saying fine, then use lineage to identify them in the
database.
3) You say you can't, because it doesn't work in the real
world.....even though your example was of lineage being the only thing
that you could use in the real world.
Doesn't that seem just a little bit of a weird argument?
Quote:
|
If you don't find the example convincing, you'll have to come up with something other than trying to bend it into something else. If you are saying that its because two people may have the same name and the same Parent_name, of course yes that would break things, but it would / equally/ stump you in real life too. And in real life, this is sometimes resolved by using chains of names, *as the example shows*. Which, in turn, shows that the people involve work with an underlying data model that contains person references. That is the whole point of the example. |
All it just shows that people can be identified by the "names" of
their ancestors, which we've seen can happily be viewed as just more
attribute values.
Do you think there's a difference between attributes and relationships
that is anything but arbitrary?
Quote:
|
If you don't find the example convincing, fine. If you choose not to understand it, fine. But stop trying to bend it into something else. So to deal with it in real life you might specify the Grandparent's name too. And if that were the same, then the Great-GrandParent as well. If that gives you the way to identify the person uniquely, excellent - you now know if you ever need to build a database for the info, you can use a table with a PK(Name, P, GP, GPP). If not, just keep on going with those ancestors. No OID's necessary. Except that 1) there is no fixed limit on the length of the chain. |
identify someone varies from person to person. well, yup, that would
no doubt be correct. I don't see any problem there to identification
and FOL. Is that an issue you have with RM or content based
addressing?
Quote:
|
2) you'll end up with an awful lot of NULLs on those tables |
issue. In fact, when we agree we don't /need/ OID's for
identification, and no doubt go on to talk about whether there are
practical reasons why they might be useful, that'd probably come up.
Quote:
|
If that's not enough and you need grandparents to distinguish them, then use that too, and so on. Just work out how you identify something in real life and then use that in the database. Yes, that's exactly what I've been doing here. No, I meant if you use someone's ancestors to identify them in real life, then that's exactly what you should use to identify them in a tuple. No, you're asking for something much stronger: that we have a fixed-format formula for identifying any person, and that the same person is always identified with the same parameters to that formula. |
because I'm not saying that.
Quote:
|
A strong requirement; sensible, too, at least for relational databases; and one this example doesn't meet. Who said that the same person will always be identified by the same fixed path? WHo said that the paths for different persons will always be of the same length? I stated neither. It seems very unlikely. |
understand why you'd think that, because it might seem like i'm
championing RM tables, but I'm not. All I am promoting is the logic of
using /content-based addressing/. It's what we use in the outside
world and should be a central component of any future 'ultimate data
model (TM)'. Hey, maybe you'll even invent it once we get this OID
stuff out your system? ;P
Quote:
|
I'm baffled why you'd think you'd corresponded to real life at all by inventing invisible numbers. They are *not* numbers. And OIDs are just a way to implement references in terms of a flat relational model. Conceptually, what we have is tuple references. |
too. Feels a bit silly now).
Quote:
|
There are no OID's in the bible. And your example showed people being successfully referred to by their parent, grandparent, etc, so its absolutely clear we don't need anything else to identify them. You're doing it again: confusing, in your wording, "parent" and "grandparent" with "the parent's name" and "the grandparent's name". |
it would be obvious I was talking about their names, given that's what
your example is about.
Interesting parallel question - would it scare you if 'you' were only
made up of values and had no magic OID number acting as a substrate,
no essential bit that was 'you'? I like not to think about it meself.
Bhuddism has the notion as a central tenet, and while I know they're
probably right, it always suprises me they are so chilled about it all
and not running around panicking. I always find OID's to be a related
topic...
Quote:
|
In fact the example is a cracker - I can use it in the future not only to explain why we don't need OID's, but also to show that identifiers can get very long, and that's why we make up things like SSN's to make life easier. Absolutely. Life in biblical times would have been much easier if every Joshua had worn a chip on his shoulder. |
Quote:
|
-- Reinier |
#1287
| ||||||||||
| ||||||||||
|
|
JOG wrote: Why on earth can't people be identified inside the database by their name, and parent's name, if that works outside? It doesn't. I thought we already agreed on that. It's the whole point of this example that it doesn't. |
lineage.
2) I respond by saying fine, then use lineage to identify them in the
database.
3) You say you can't, because it doesn't work in the real
world.....even though your example was of lineage being the only thing
that you could use in the real world.
Doesn't that seem just a little bit of a weird argument?
Quote:
|
If you don't find the example convincing, you'll have to come up with something other than trying to bend it into something else. If you are saying that its because two people may have the same name and the same Parent_name, of course yes that would break things, but it would / equally/ stump you in real life too. And in real life, this is sometimes resolved by using chains of names, *as the example shows*. Which, in turn, shows that the people involve work with an underlying data model that contains person references. That is the whole point of the example. |
All it just shows that people can be identified by the "names" of
their ancestors, which we've seen can happily be viewed as just more
attribute values.
Do you think there's a difference between attributes and relationships
that is anything but arbitrary?
Quote:
|
If you don't find the example convincing, fine. If you choose not to understand it, fine. But stop trying to bend it into something else. So to deal with it in real life you might specify the Grandparent's name too. And if that were the same, then the Great-GrandParent as well. If that gives you the way to identify the person uniquely, excellent - you now know if you ever need to build a database for the info, you can use a table with a PK(Name, P, GP, GPP). If not, just keep on going with those ancestors. No OID's necessary. Except that 1) there is no fixed limit on the length of the chain. |
identify someone varies from person to person. well, yup, that would
no doubt be correct. I don't see any problem there to identification
and FOL. Is that an issue you have with RM or content based
addressing?
Quote:
|
2) you'll end up with an awful lot of NULLs on those tables |
issue. In fact, when we agree we don't /need/ OID's for
identification, and no doubt go on to talk about whether there are
practical reasons why they might be useful, that'd probably come up.
Quote:
|
If that's not enough and you need grandparents to distinguish them, then use that too, and so on. Just work out how you identify something in real life and then use that in the database. Yes, that's exactly what I've been doing here. No, I meant if you use someone's ancestors to identify them in real life, then that's exactly what you should use to identify them in a tuple. No, you're asking for something much stronger: that we have a fixed-format formula for identifying any person, and that the same person is always identified with the same parameters to that formula. |
because I'm not saying that.
Quote:
|
A strong requirement; sensible, too, at least for relational databases; and one this example doesn't meet. Who said that the same person will always be identified by the same fixed path? WHo said that the paths for different persons will always be of the same length? I stated neither. It seems very unlikely. |
understand why you'd think that, because it might seem like i'm
championing RM tables, but I'm not. All I am promoting is the logic of
using /content-based addressing/. It's what we use in the outside
world and should be a central component of any future 'ultimate data
model (TM)'. Hey, maybe you'll even invent it once we get this OID
stuff out your system? ;P
Quote:
|
I'm baffled why you'd think you'd corresponded to real life at all by inventing invisible numbers. They are *not* numbers. And OIDs are just a way to implement references in terms of a flat relational model. Conceptually, what we have is tuple references. |
too. Feels a bit silly now).
Quote:
|
There are no OID's in the bible. And your example showed people being successfully referred to by their parent, grandparent, etc, so its absolutely clear we don't need anything else to identify them. You're doing it again: confusing, in your wording, "parent" and "grandparent" with "the parent's name" and "the grandparent's name". |
it would be obvious I was talking about their names, given that's what
your example is about.
Interesting parallel question - would it scare you if 'you' were only
made up of values and had no magic OID number acting as a substrate,
no essential bit that was 'you'? I like not to think about it meself.
Bhuddism has the notion as a central tenet, and while I know they're
probably right, it always suprises me they are so chilled about it all
and not running around panicking. I always find OID's to be a related
topic...
Quote:
|
In fact the example is a cracker - I can use it in the future not only to explain why we don't need OID's, but also to show that identifiers can get very long, and that's why we make up things like SSN's to make life easier. Absolutely. Life in biblical times would have been much easier if every Joshua had worn a chip on his shoulder. |
Quote:
|
-- Reinier |
 |
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.