On Fri, 2009-11-13 at 14:30 +1000, Angus Mann wrote:

> > Here's part of the confusion:
> >
> > If you were to express the number of microseconds since 1970 in a
> > decimal number, it would indeed take 16 digits.
> >
> > But uniqid() returns a /13 character string/, not a 13 digit number. The
> > string is actually a hexadecimal number (and thus can express a greater
> > range of values than a decimal number within those 13 characters).
> >
> > -John
> Ahh! The moment when the penny drops. I was looking at the result as a 
> number, not a string.
> Solution to problem = use uniqid()

You say you don't want to use the auto increment field for this 'unique'
value, but then you are considering using something which is likely to
produce the exact same value as someone else may have in their database,
and then you plan on merging the data!

If I were you I'd either:

a) find another way instead t create a number that is unique to you,
something like a namespace kind of thing
b) don't merge the data directly, but think of a smart way of adding it
that avoids collisions

Personally, I reckon it's best going with the latter. The other database
should have extra fields in: one for their own auto incremental field,
one to store the value of your auto increment (not unique to avoid
problems if they source data from many other exterior databases) and one
field to indicate where the data came from.

I really do think that a bit of work on the interface between your two
databases would reap dividends, as it could make it a whole lot easier
to determine where a problem came from if one occurs, and to my mind
makes things just a little bit easier in the long run.


Reply via email to