January 17, 2018 at 1:16 am
Lynn, that's marvellous. You have once again utterly ignored the logic of the presented arguments on either side, and have decided that the relevant comment to make is to come in and white knight for someone who, at this point, can only possibly be trolling by cowardly sneaking in side comments - into a thread he has already indicated he would no longer participate in - via condescending responses to comments which never addressed him in the first place.. Especially given that his first comment, while based on a failure to comprehend, said "this seems possible with some work", and now, without having shown any indication of improving comprehension, suggests that I am claiming to have disproved the Church-Turing thesis. So either he thinks it is possible and I have somehow disproved the Church-Turing thesis, or he is deliberately constructing ridiculous strawmen, which he knows to be strawmen, and trying to inject them without having to engage the actual arguments, just to be a git. I assume the latter. Perhaps you disagree.
January 17, 2018 at 7:03 am
Don Halloran - Wednesday, January 17, 2018 1:16 AMLynn, that's marvellous. You have once again utterly ignored the logic of the presented arguments on either side, and have decided that the relevant comment to make is to come in and white knight for someone who, at this point, can only possibly be trolling by cowardly sneaking in side comments - into a thread he has already indicated he would no longer participate in - via condescending responses to comments which never addressed him in the first place.. Especially given that his first comment, while based on a failure to comprehend, said "this seems possible with some work", and now, without having shown any indication of improving comprehension, suggests that I am claiming to have disproved the Church-Turing thesis. So either he thinks it is possible and I have somehow disproved the Church-Turing thesis, or he is deliberately constructing ridiculous strawmen, which he knows to be strawmen, and trying to inject them without having to engage the actual arguments, just to be a git. I assume the latter. Perhaps you disagree.
Well in everybody's defense on either side, new inventions and discoveries aren't really that common, and for that matter, Don I think you should always be prepared for naysayers. Furthermore, while I'd have to agree that "insufferable git" probably wasn't incredibly productive I'm also thinking that church-turing isn't in any danger from Don's suggestions about key properties.
Also, if we can deduce the sets described by the keys, and if the keys are equal without the deduction, the sets described by the keys really cannot be unequal, otherwise we wouldn't be able to communicate accurate descriptions of sets, so yes if the keys a, b and c are equal with all the transitive properties of equality, how could the sets described by these keys be unequal, so yeah, I don't get what Tom's saying either but I'm just as ready to admit that maybe I'm not academically up for any of these discussions 😉
How could we go about finding what properties or circumstances arise from using perfectly valid keys that despite being valid might describe intersecting sets, and if these properties or circumstances good or bad can be shown to arise from whether the sets intersect or not?
January 17, 2018 at 7:53 am
patrickmcginnis59 10839 - Wednesday, January 17, 2018 7:03 AMHow could we go about finding what properties or circumstances arise from using perfectly valid keys that despite being valid might describe intersecting sets, and if these properties or circumstances good or bad can be shown to arise from whether the sets intersect or not?
In my mind these describe two difference circumstances which do not overlap, so we shouldn't have to give up any good properties of either the normal definition of keys, nor the "key set" definition of keys. These are essentially two different kinds of key which both function as keys, but are structurally incompatible except where the key set consists of a single tuple (which is always the case traditionally), in which case they are not merely compatible, they're identical.
I'll move away from specific examples with "real world" semantics and try a more abstract example instead. Let's say I define some table as follows. It has a multi-column key (k1, k2), and some other properties which I'll just represent as a single "p" data element:::
create table T (k1 int not null, k2 int not null, p char, constraint PK_T primary key (k1, k2))
The following inserts contain no key violations:
insert T (k1, k2, p) select 1, 1, 'a'
insert T (k1, k2, p) select 1, 2, 'b'
How is the check for the violation performed? Well, when the row with key 1, 2 is inserted we make sure there is no existing row that already has k1 = 1 and k2 = 2.
This represents the case of a key which is defined as existing within a single tuple. So far we're just looking at regular old keys, where the key is a subset of the columns of the table, and every individual row's key exists as the values of some of the columns on that same row. There's nothing here to do with my proposal. To be more specific, I am not proposing that in cases like this, we should treat the key (k1, k2) as a "set based key". In other words, I am not suggesting that the insert with key 1, 2 should fail because the set {1, 2} intersects with the "set" {1, 1}. I put set in quotes because this is, of course, not a set, since sets can't have repeated elements.
OK, so that's what a "key set" isn't. I just want to be totally clear in case anyone is thinking I mean something like that. So what is this thing I'm calling a "key set"?
Let me define a new table. We'll start off with a single column for the key:
create table T(k1 int not null, p char, constraint PK_T primary key (k1))
The key column "k1" obviously takes its values from some domain. I then discover that my entities, whatever they might be, actually need two values from this domain in order to be uniquely identified. Well, my first adjustment would be to simply add a "k2" column, just like the example above.
But then I discover that it's really three values that are needed. And then 4. OK, I keep adding columns. But then - horror of horrors, I discover that an arbitrary number of values are possible! I don't know how many candidate values there might be to identify some particular entity. Sometimes it might be one value, sometimes it might be 8 values. I can't just create a table with 8 columns - it won't work, because key columns cannot be null. So if I define the table in such a way as to be able to store my "8 value" entity in an identifiable way, I won't be able to store my "1 value" entity, because the other 7 key columns would have no legitimate value.
So what I would need to do instead is turn my key columns into key rows. Some entities have a single row of data containing their single key value. Other entities have multiple rows of data containing their multitude of key values. We then say that these "key rows" are associated with "that row over there, containing all of the non-key stuff about this entity".
Right, so when I try to do inserts now, what does the test for key violations look like? I claim that we should use a test of intersection. Say we have an existing entity with a key set {1, 2, 3}. I then try to store a new entity with a key set {3, 7, 9, 11, 21, 45}. Under my proposal this insert would fail, because the key sets intersect.
Perhaps it is more clear now why I have said that intersection reduces to equality. If the "key set" always contains just a single member (which is of course always true under current relational modelling, since under current relational modelling the key sits on a single row along with the rest of the data), then a test of intersection is the same as a test of equality - if a set with a single member intersects with another set with a single member, then the two sets are identical. Or, said another way, existing key checks are already tests of intersection, but are also always a special case - the set contains a single member.
Just to reiterate, when I say "a single member" I don't mean a single column. We can of course have multi-column keys right now. But we can't have multi row keys. The idea is simply incoherent under relational models as they exist today.
Under my proposal I can also still have a multi column key set, but each member of that key set is now simply a tuple consisting of multiple elements (instead of a tuple consisting of a single element). The intersection test then says "if any tuple in one key set is identical with any tuple in another key set, then a key violation has occurred".
Now, does this kind of situation ever arise? I believe it quite often does, but people have to "solve" it a different way. We create some kind of surrogate - say, an identity column, on our row, and declare it a key. We then add these "other values of arbitrary cardinality" to a second table, and create a foreign key from this second table back to the surrogate. But what if that multitude was our only natural key? We've abandoned the natural key! Once we add a surrogate like this, I can happily go about inserting data that *should* be prohibited, because the "natural key" - the set of values of arbitrary cardinality - isn't tested for "key violations", because it can't be tested in this way! That's not something that exists under current relational models. I can't declare those multiple rows to be "a key".
January 17, 2018 at 8:36 am
Don Halloran - Wednesday, January 17, 2018 1:16 AMLynn, that's marvellous. You have once again utterly ignored the logic of the presented arguments on either side, and have decided that the relevant comment to make is to come in and white knight for someone who, at this point, can only possibly be trolling by cowardly sneaking in side comments - into a thread he has already indicated he would no longer participate in - via condescending responses to comments which never addressed him in the first place.. Especially given that his first comment, while based on a failure to comprehend, said "this seems possible with some work", and now, without having shown any indication of improving comprehension, suggests that I am claiming to have disproved the Church-Turing thesis. So either he thinks it is possible and I have somehow disproved the Church-Turing thesis, or he is deliberately constructing ridiculous strawmen, which he knows to be strawmen, and trying to inject them without having to engage the actual arguments, just to be a git. I assume the latter. Perhaps you disagree.
Well, that doesn't give you the right to call someone an inappropriate name. That was totally unprofessional and uncalled for in this environment and I am calling you out on it. As soon as you start calling people names you have demonstrated that you no longer have anything intellectual to say.
If Tom is misunderstanding something you wrote, how about working on figuring out what he got wrong and doing it in a professional manner. One way is to start asking questions to trying and figure where the misunderstanding arises in your proposal. Again, I don't have a dog in this race but I would like to see a professional, passionate (no name calling) discussion. This way I can hopefully learn something. As long as the both of you aren't willing to work to at least some understanding and common ground that won't happen. To that end I haven't seen Tom drop to the level of name calling.
This is your idea, you need to defend it and if people don't have an understanding then it is up to you to help them understand it.
January 17, 2018 at 5:32 pm
Lynn Pettis - Wednesday, January 17, 2018 8:36 AMWell, that doesn't give you the right to call someone an inappropriate name
OK Lynn. So " I probably ought just to have suggested that you learn some SQL" is OK by you, as are other character accusations like "hard headed", "you think you are always right and the rest of the world is wrong", and provable sophistry of the kind Tom is engaged in. But the word "git" is, in your mind, where we should draw the line. I acknowledge your admission of hypocrisy.
January 17, 2018 at 8:50 pm
Don Halloran - Wednesday, January 17, 2018 5:32 PMLynn Pettis - Wednesday, January 17, 2018 8:36 AMWell, that doesn't give you the right to call someone an inappropriate nameOK Lynn. So " I probably ought just to have suggested that you learn some SQL" is OK by you, as are other character accusations like "hard headed", "you think you are always right and the rest of the world is wrong", and provable sophistry of the kind Tom is engaged in. But the word "git" is, in your mind, where we should draw the line. I acknowledge your admission of hypocrisy.
Actually, it looks like you are the one that always thinks they are right. I know when I am wrong and have admitted when needed. Too bad you don't seem capable of it.
I really did want to learn from a professional, passionate discuss between you and Tom. I guess we wont get that discussion so your idea will probably just die a slow death, at least here. Good luck in the future, I honestly hope you have great successes ahead.
January 17, 2018 at 9:10 pm
Lynn Pettis - Wednesday, January 17, 2018 8:50 PMActually, it looks like you are the one that always thinks they are right. I know when I am wrong and have admitted when needed. Too bad you don't seem capable of it.I really did want to learn from a professional, passionate discuss between you and Tom. I guess we wont get that discussion so your idea will probably just die a slow death, at least here. Good luck in the future, I honestly hope you have great successes ahead.
You've misunderstood me. Tom accused me of not knowing any SQL. You accused me of being hard headed. You also accused me of thinking I was always right and the rest of the world is wrong. All of these are accusations against a person. Yours are accusations against my character. His is an accusation against my underlying expertise on a subject. None are attacks on an argument. All are ad hominem.
Accusing someone of being a "git" is precisely the same kind of thing. It's claim about someone's character, and an ad hominem But at least I first made the effort to engage Tom's absurd argument and demonstrate that it was plainly absurd, and from the nature of the absurdity thus established, I concluded that Tom was being a git. You, on the other hand, have engaged in ad hominem as the entirety of your argument per se, rather than drawing it as a conclusion.
January 18, 2018 at 8:54 am
Don Halloran - Wednesday, January 17, 2018 9:10 PMLynn Pettis - Wednesday, January 17, 2018 8:50 PMActually, it looks like you are the one that always thinks they are right. I know when I am wrong and have admitted when needed. Too bad you don't seem capable of it.I really did want to learn from a professional, passionate discuss between you and Tom. I guess we wont get that discussion so your idea will probably just die a slow death, at least here. Good luck in the future, I honestly hope you have great successes ahead.
You've misunderstood me. Tom accused me of not knowing any SQL. You accused me of being hard headed. You also accused me of thinking I was always right and the rest of the world is wrong. All of these are accusations against a person. Yours are accusations against my character. His is an accusation against my underlying expertise on a subject. None are attacks on an argument. All are ad hominem.
Accusing someone of being a "git" is precisely the same kind of thing. It's claim about someone's character, and an ad hominem But at least I first made the effort to engage Tom's absurd argument and demonstrate that it was plainly absurd, and from the nature of the absurdity thus established, I concluded that Tom was being a git. You, on the other hand, have engaged in ad hominem as the entirety of your argument per se, rather than drawing it as a conclusion.
I fully understand, you are right and I am wrong. Bye bye.
Viewing 8 posts - 31 through 37 (of 37 total)
You must be logged in to reply to this topic. Login to reply