Now you're just getting silly. ?What if the application sets all rowids,
everywhere to 1? ?The fact is, the chance of collision on a UUID is pretty
astronomically low as long as a decent source of entropy is used
(see?http://en.wikipedia.org/wiki/Universally_unique_identifier#Random_UUID_probability_of_duplicates).
?Yes, some application might not generate proper UUIDs, but that's true with
any scheme that needs to coordinate disconnected data editing or generation on
multiple machines. ?There are lots of applications out there that use UUIDs
pretty successfully. ?Are they a perfect solution? ?Of course not, but then,
what is? ?But for that particular problem domain they have proved viable.
Mind you, the original article linked was guilty of gross over-generalization,
and got the amount of randomess in a UUID wrong (it's 122 bits, not 124).
Peter? ?
On Wednesday, May 20, 2015 4:38 PM, Keith Medcalf <kmedcalf at dessus.com>
wrote:
On the other hand, perhaps both tablets implement the same PRNG with the same
seed.? You will then have the same HUID's generated on both and have the exact
same problem.? Addressing the problem using Hope and Pray is not a very robust
solution.? It would be much better to solve the problem using a deterministic
solution than a prayer based one.? Even though God hears all prayers, the
answer might be no ...
> -----Original Message-----
> From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users-
> bounces at mailinglists.sqlite.org] On Behalf Of Steven M. McNeese
> Sent: Wednesday, 20 May, 2015 16:09
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] AUTOINC vs. UUIDs
>
> You misunderstood. If an application running on a tablet for 2 users add
> rows to a local database with an auto increment key, each would get a key
> based on their database an let's say for grins they both start with a new
> clean database. User 1 gets key 1 and user 2 gets key 1. Now they push
> their data to a server each with key 1 but different data. That doesn't
> work. Both records needs to be added to the server database - a collection
> of all the data collected on the client tablets.
>
> Sent from my iPhone
>
> > On May 20, 2015, at 4:38 PM, Jean-Christophe Deschamps
> <jcd at antichoc.net> wrote:
> >
> > At 23:24 20/05/2015, you wrote:
> >
> >> On Wed, May 20, 2015 at 2:20 PM, Steven M. McNeese
> >> <steven.mcneese at freedomparkdfw.com> wrote:
> >> > Often times people will use GUIDs as primary keys when different
> systems need to generate
> >> > rows and then merge together. Like an application that works with
> offline clients that push the
> >> > data to a server when the connect. However there are other ways of
> accomplishing the same thing.
> >>
> >> For curiosity - Is there a site/blog post somewhere
> >> enumerating/listing these other ways ?
> >
> > I don't know, but let's say your rowids range from -9223372036854775807
> to 9223372036854775807, that's 18446744073709551614 possible rowids.
> >
> > Imagine that in 50 years, the total population on Earth will grow to
> (say) 50 billion people (I hope it won't!).
> >
> > 18 446 744 073 709 551 614 / 50 000 000 000 = 368 934 881.474 191 032 28
> >
> > That leaves you the possibility to assign a unique identifier to every
> potential client on the planet (and a big one) in nearly 369 million
> servers concurrently without the faintest risk of collision.
> >
> > At this rate, you may limit rowids to only positive integers ... and
> hire a large army of telemarketers.
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users at mailinglists.sqlite.org
> > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
>
> _______________________________________________
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
