On Wed, Nov 12, 2008 at 9:06 AM, Justus Ohlhaver <ohlhaver / gmail.com> wrote:
> Todd Benson wrote:
>> On Wed, Nov 12, 2008 at 8:47 AM, Jan Friedrich
>> <janfri.rubyforge / gmail.com> wrote:
>>>  Digest::MD5.hexdigest('Peter')
>>>  # => "6fa95b1427af77b3d769ae9cb853382f"
>>>
>>> Regards
>>> Jan
>>
>> Unless I'm missing something here, strings are just numbers in order.
>> Why encode/encrypt?
>>
>> Most db's should handle natural keys.
>>
>> If absolutely necessary to store as number strings (I can't see why),
>> look at #pack and #unpack.
>>
>
> Thanks a lot everybody.  I'm really impressed by the quick and useful
> feedback.
>
> Todd, I was told that searching by integers instead of strings would
> speed up performance when using large mysql tables. Is that not so?

To be honest, I know almost nothing about mysql.  I will say, however,
that you should try natural keys and see how the performance works
(testing).  PostgreSQL, for example, claims you gain no more
performance on any natural key (be it integer, character, otherwise).
The true bottleneck is almost always in the application.  But, I don't
know your exact situation.

From what you have said, it seems like you are looking for a primary
key that's unique and fast.  Most db's that are set up correctly do a
"behind-the-scenes" lookup for your key; which means that there is an
ID (number) assigned to your element.  The search is definitely what
people are concerned about, but having a string turned into a number
won't help you there, unless it's like a password or something.

If you want the string compacted, then follow some of the other suggestions.

hth,
Todd