Re: Hashes from composite keys?
Date: Fri, 23 Jul 2010 21:30:12 -0300
Message-ID: <4c4a3418$0$11830$9a566e8b_at_news.aliant.net>
Karsten Wutzke wrote:
> On 24 Jul., 00:58, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
>>Karsten Wutzke wrote:
>>
>>>On Jul 23, 11:14 pm, Eric <e..._at_deptj.eu> wrote:
>>
>>>>On 2010-07-23, Karsten Wutzke <kwut..._at_web.de> wrote:
>>
>>>>>On 23 Jul., 22:22, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>>
>>>>>>Karsten Wutzke wrote:
>>
>>>>>>>Hello,
>>
>>>>>>>what are the best practices for generating hash codes from composite
>>>>>>>keys? I need to mimic something like what a composite index does. In
>>>>>>>fact, it's for mapping between relational keys and object IDs.
>>
>>>>>>>Can anyone point me into the right direction please?
>>
>>>>>>>Karsten
>>
>>>>>>Yes, I can point you in the right direction. Simply turn completely
>>>>>>around from what you are trying to do, and go in the opposite direction.
>>
>>>>>One of the most useless comments on the Usenet I've read in my whole
>>>>>life. Congratulations. You must have a lot of time for writing such a
>>>>>crap. If you think you are cool, you're not.
>>
>>>>>Anyone else with a useful tip? XORing the individual elements?
>>
>>>>>Karsten
>>
>>>>He genuinely believes that both what you want to do and why you want to
>>>>do it are very bad ideas indeed. There are sensible arguments behind
>>>>that opinion, but presenting them here usually results only in a spate
>>>>of ill-considered counter-arguments from people who know nothing about
>>>>it. They won't answer your question either.
>>
>>>OK.
>>
>>>>If you want hash codes, they are a topic in their own right, which you
>>>>can look up, or ask about elsewhere. The fact that the data you want to
>>>>hash happens to be a composite key in a database is pretty-much
>>>>irrelevant.
>>
>>>Yes. I had I reason to believe I'd find the people that know what I'm
>>>talking about HERE, not elsewhere. That's why I also asked for a
>>>direction, not a solution primarily.
>>
>>>>Alternatively, you may wish to take a step back from your problem,
>>>>and ask again the questions to which your answers were "mapping" and
>>>>"hash codes". Here may or may not be the right place for that.
>>
>>>>Finally, if you think that his response, or even mine, are the most
>>>>useless comments on Usenet (_not_ "the Usenet"), you haven't read very
>>>>much of it. Asking you to re-consider the reasoning that led to your
>>>>question is potentially very useful indeed.
>>
>>>>Eric
>>
>>>Well, as I'm thinking about it, there's nothing I can come up with to
>>>avoid generating robust hash codes from composite keys.
>>
>>You are too focused on how. You have lost touch with what.
>>
>>A composite key is a key. Keys provide logical identity. Since you were
>>looking for something that provides identity, you were already done
>>before you even started. From that observation, the analysis of what you
>>are doing starts by noting that anything else you add will simply
>>introduce redundancy then goes downhill from there.
>>
>>>If you think
>>>the direction is "backward", why not be more verbose?
>>
>>Because I cannot afford to provide a post-secondary education for free
>>to everyone who hasn't yet grasped the fundamentals.
> > But you can give philosophical answers and afford an off-topic > discussion in such a dry thread? That doesn't sound logical.
My answers have been strictly factual and entirely on-topic for this newsgroup.
>>The deficit in your
>>understanding may not be your fault, but ultimately it is your
>>responsibility to eliminate it.
>>
>>
>>>Instead of
>>>discussing other issues, you might have just showed me a direction, as
>>>I believe, it's not something that hasn't been solved before. I just
>>>cannot find it. My XORing test already failed with 4 rows, so, as you
>>>can see, I probably have to find out the hard way.
>>
>>If your hash code is to maintain identity, it must have at least as many
>>unique possible values as the original key.
> > Now that sounds logical and gives me a direction. > >
>>If you understand that, you
>>will immediately understand why simply XORing the bytes cannot possibly
>>work.
> > Yes, it's the wrong approach. The problem is: I can't predict what the > composite key will be like. Chances are the types are anything that > SQL allows in primary keys, such as VARCHAR(100) or even higher. Many > of my keys are short codes such as CHAR(2), but also INTEGERs, > BOOLEANs, and DATETIMEs. I suspect the problem with the larger > character strings, but it stops right there.
I can speculate on what you are trying to do, but frankly I don't know for sure what you are doing. I do know for certain you are on a misguided path.
The sooner you get off that path and start learning about data management fundamentals, the better off everyone will be.
> Java has several different hashCode implementations AFAIK, but I don't > know if they are useful for persistent object identity at all. Just > found out that "Ca".hashCode() and "DB".hashCode() already produce a > collision, making the default implementation factually useless. > *scratch*
Hashes are generally used for hash tables. Hash table implementations allow for and handle collisions. Thus, hashes for hash tables generally use some sort of lossy compression mapping a larger set of possible values onto a smaller set of values.
Once you understand that, you will understand that hash codes neither provide nor preserve identity.
> Persistent object identity seems to be a much more mighty task than > expected to be honest.
And a much less desirable task as well. Contrary to what you may have read or heard, object identity is worse than useless for data management. Received on Sat Jul 24 2010 - 02:30:12 CEST