Is spl_object_hash unique in the SQL sense? Can it be used as aunique SQL db column?

Does anyone know definitely whether the results of spl_object_hash be safely used as a unique database column?

On 6/11/2012 8:16 PM, kurtk@pobox.com wrote:
> Does anyone know definitely whether the results of spl_object_hash be safely used as a unique database column?

No, hashes can never guaranteed to be unique.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

> No, hashes can never guaranteed to be unique.

I opted to use

md5(uniqid());

to create a unique key.

On 6/12/2012 2:47 PM, kurtk@pobox.com wrote:
>> No, hashes can never guaranteed to be unique.
>
> I opted to use
>
> md5(uniqid());
>
> to create a unique key.
>

Still not guaranteed to be unique. Hashes never are. But if you've
only got a few thousand items, the chances of a collision are slim.

This is why databases have sequence or auto-increment values.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Tue, 12 Jun 2012 11:47:04 -0700 (PDT), kurtk@pobox.com wrote:
>> No, hashes can never guaranteed to be unique.
>
> I opted to use
>
> md5(uniqid());
>
> to create a unique key.

Still not guaranteed to be unique. You've even got a defined 13-hexdigit
space thing what you're hashing. Which means as soon as you've got more
than 4,503,599,627,370,495 entries, you are GUARANTEED a collision. That
seems like a lot, but you're down to a one in a billion shot at a
collision when you've got a few million entries. And everybody knows,
that one in a billion changes turn up nine times in ten.

--
48. I will treat any beast which I control through magic or technology
with respect and kindness. Thus if the control is ever broken, it
will not immediately come after me for revenge.
--Peter Anspach's list of things to do as an Evil Overlord

On 6/12/2012 3:26 PM, Peter H. Coffin wrote:
> On Tue, 12 Jun 2012 11:47:04 -0700 (PDT), kurtk@pobox.com wrote:
>>> No, hashes can never guaranteed to be unique.
>>
>> I opted to use
>>
>> md5(uniqid());
>>
>> to create a unique key.
>
> Still not guaranteed to be unique. You've even got a defined 13-hexdigit
> space thing what you're hashing. Which means as soon as you've got more
> than 4,503,599,627,370,495 entries, you are GUARANTEED a collision. That
> seems like a lot, but you're down to a one in a billion shot at a
> collision when you've got a few million entries. And everybody knows,
> that one in a billion changes turn up nine times in ten.
>

Peter,

I haven't figured out the exact numbers, but I suspect it's much less
than one in a billion to have a 50-50 chance.

After all - it only takes 24 people to have a 50-50 chance two of them
have the same birthday.

Odds go down quite a bit more quickly than you think!

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

On Jun 12, 7:47*pm, "ku...@pobox.com" <ku...@pobox.com> wrote:
> > No, hashes can never guaranteed to be unique.
>
> I opted to use
>
> * md5(uniqid());
>
> to create a unique key.

Why bother hashing it, why not just use the uniqid() value directly?

On 13.6.2012 13:09, Captain Paralytic wrote:
> On Jun 12, 7:47 pm, "ku...@pobox.com" <ku...@pobox.com> wrote:
>>> No, hashes can never guaranteed to be unique.
>>
>> I opted to use
>>
>> md5(uniqid());
>>
>> to create a unique key.
>
> Why bother hashing it, why not just use the uniqid() value directly?

uniqid() is not truly unique either Only truly unique value is the one
generated by DB (if we are talking about DB data).

On Jun 13, 12:40*pm, Goran <go...@nospam.com> wrote:
> On 13.6.2012 13:09, Captain Paralytic wrote:
>
> > On Jun 12, 7:47 pm, "ku...@pobox.com" <ku...@pobox.com> wrote:
> >>> No, hashes can never guaranteed to be unique.
>
> >> I opted to use
>
> >> * md5(uniqid());
>
> >> to create a unique key.
>
> > Why bother hashing it, why not just use the uniqid() value directly?
>
> uniqid() is not truly unique either Only truly unique value is the one
> generated by DB (if we are talking about DB data).

Err I know that! but hashing it actually REDUCES it's uniqueness.