[sqlite] AUTOINC vs. UUIDs

{{I just got a bounced message.. Reposting}} I've been watching this thread from the beginning with great interest, and I still don't see the difference between using a UUID or an auto-inc integer as a PK at the very raw, basic level. The database will only see them as a string of bits or bytes

[sqlite] AUTOINC vs. UUIDs

I've been watching this thread from the beginning with great interest, and I still don't see the difference between using a UUID or an auto-inc integer as a PK at the very raw, basic level. The database will only see them as a string of bits or bytes and handle accordingly. IMO, using UUID is an

[sqlite] AUTOINC vs. UUIDs

On 2015-05-21 9:14 PM, Stephen Chrzanowski wrote: > {{I just got a bounced message.. Reposting}} Both of your attempts got through. You got a bounce because you sent it to an invalid list address in addition to a valid one; one bounced the other didn't. > I've been watching this thread from

[sqlite] AUTOINC vs. UUIDs

On Wed, May 20, 2015 at 11:52:08PM +, Peter Aronson wrote: > 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 >

[sqlite] AUTOINC vs. UUIDs

half Of Simon Slavin >> Sent: Wednesday, 20 May, 2015 14:38 >> To: sqlite-users at mailinglists.sqlite.org >> Subject: Re: [sqlite] AUTOINC vs. UUIDs >> >> On 20 May 2015, at 8:52pm, Kees Nuyt wrote: >> >>> The autoincrement clause causes an entry in the sql

[sqlite] AUTOINC vs. UUIDs

On 2015-05-21 12:16 PM, James K. Lowden wrote: > On Wed, 20 May 2015 19:05:29 +0100 > Simon Slavin wrote: > >> Posting this not because I agree with it but because the subject has >> come up here a couple of times. >> >>

[sqlite] AUTOINC vs. UUIDs

On Thu, 21 May 2015 13:44:15 +0200 Mark Straver wrote: > > Oh and the other feature! of UUIDs is merging databases... if I > > have a database deployed to 15 customers, each with their own ORGID > > I can easily throw them in the same database without worrying about > > fixing up primary keys

[sqlite] AUTOINC vs. UUIDs

On Wed, 20 May 2015 19:05:29 +0100 Simon Slavin wrote: > Posting this not because I agree with it but because the subject has > come up here a couple of times. > > > > > "Today, I?ll talk about

[sqlite] AUTOINC vs. UUIDs

On 5/21/2015 1:37 PM, Valentin Davydov wrote: > Moreover, there are widespread examples of colliding UUIDs, say > EBD0A0A2-B9E5-4433-87C0-68B6B72699C7. This particular issue ( http://lists.gnu.org/archive/html/bug-parted/2011-06/msg00026.html ) didn't happen because two independent UUID

[sqlite] AUTOINC vs. UUIDs

On 21/05/2015 09:33, J Decker wrote: > chance of collision is slim... it's a truly large amount of bits... > There's libuuid for linux, and builtin functions for windows to create them. The chance of collision is only slim if you (as some people have already indicated) have a proper entropy

[sqlite] AUTOINC vs. UUIDs

> > As a result, I don't think it's wise to use them, objectively speaking. It has > very little to do with having used them in the past myself or not (OT: that is > actually a psychological trap employed by many shady business models ;) ). > I do hope that if you use them, you never run into

[sqlite] AUTOINC vs. UUIDs

On Thu, May 21, 2015 at 11:37 AM, Valentin Davydov wrote: > On Wed, May 20, 2015 at 11:52:08PM +, Peter Aronson wrote: > > 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 > >

[sqlite] AUTOINC vs. UUIDs

tophe Deschamps > > Sent: Wednesday, 20 May, 2015 15:38 > > To: General Discussion of SQLite Database > > Subject: Re: [sqlite] AUTOINC vs. UUIDs > > > > At 23:24 20/05/2015, you wrote: > > > > >On Wed, May 20, 2015 at 2:20 PM, Steven M. McNeese &

[sqlite] AUTOINC vs. UUIDs

Sorry to be argumentative. I'll drop it. On Thu, May 21, 2015 at 4:44 AM, Mark Straver < sqlite-users-list at palemoon.org> wrote: > On 21/05/2015 09:33, J Decker wrote: > > chance of collision is slim... it's a truly large amount of bits... > > There's libuuid for linux, and builtin functions

[sqlite] AUTOINC vs. UUIDs

On 2015-05-21 01:52 AM, Peter Aronson wrote: > 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 >

[sqlite] AUTOINC vs. UUIDs

On 20 May 2015, at 11:18pm, Scott Doctor wrote: > I can see the issue. For instance, an invoice ID related to inventory, where > the invoice ID is the PK number. Two salesmen on their iPads take an order > where their local database assigns the same PK number. When merged you have > two

[sqlite] AUTOINC vs. UUIDs

On 5/20/15, R.Smith wrote: > > ANY solution that > relies on something not guaranteed is a bad solution. Here is a disturbing truth: There are no guarantees. Those transistors that make up your CPU - they turn on and off when current is applied to their gate *with a certain probability*. The

[sqlite] AUTOINC vs. UUIDs

"Just to chime in here: First off, how are you going to generate them? How will you avoid collisions? Why should it be necessary to using that much storage space for a primary key and what's the reason for not using blazingly-fast integers?..." chance of collision is slim... it's a truly large

[sqlite] AUTOINC vs. UUIDs

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

; 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

[sqlite] AUTOINC vs. UUIDs

day, 20 May, 2015 21:42 > > To: General Discussion of SQLite Database > > Subject: Re: [sqlite] AUTOINC vs. UUIDs > > > > On Wed, May 20, 2015 at 7:20 PM, R.Smith wrote: > > > > > > > > On 2015-05-21 01:52 AM, Peter Aronson wrote: > > > > &g

[sqlite] AUTOINC vs. UUIDs

At 22:50 20/05/2015, you wrote: >Just to chime in here: I think using UUIDs for primary keys is an >absolutely >terrible idea, instead. First off, how are you going to generate them? How >will you avoid collisions? Why should it be necessary to using that much >storage space for a primary key

[sqlite] AUTOINC vs. UUIDs

Just to chime in here: I think using UUIDs for primary keys is an absolutely terrible idea, instead. First off, how are you going to generate them? How will you avoid collisions? Why should it be necessary to using that much storage space for a primary key and what's the reason for not using

[sqlite] AUTOINC vs. UUIDs

On Wed, 20 May 2015 12:36:43 -0700, Scott Doctor wrote: > Given a field that is a primary key with auto-increment, does sqlite > store an integer that gets incremented, or does it look at the last row > and increment its value? The autoincrement clause causes an entry in the sqlite_sequence

[sqlite] AUTOINC vs. UUIDs

On 2015-05-20 09:36 PM, Scott Doctor wrote: > > Given a field that is a primary key with auto-increment, does sqlite > store an integer that gets incremented, or does it look at the last > row and increment its value? > SQLite stores an Integer that gets incremented if the PK is declared

[sqlite] AUTOINC vs. UUIDs

On Wed, May 20, 2015 at 7:20 PM, R.Smith wrote: > > On 2015-05-21 01:52 AM, Peter Aronson wrote: > >> 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

[sqlite] AUTOINC vs. UUIDs

On 20 May 2015, at 8:52pm, Kees Nuyt wrote: > The autoincrement clause causes an entry in the sqlite_sequence > table. It's interesting that SQLite uses tables inside the user database for private purposes like this. A certain wall is broken when the designers choose this option. SQLite

[sqlite] AUTOINC vs. UUIDs

On Wed, May 20, 2015 at 8:05 PM, Simon Slavin wrote: > Posting this not because I agree with it but because the subject has come > up here a couple of times. > > < > https://www.clever-cloud.com/blog/engineering/2015/05/20/Why-Auto-Increment-Is-A-Terrible-Idea/ > > > > "Today, I?ll talk about

[sqlite] AUTOINC vs. UUIDs

> On May 20, 2015, at 8:05 PM, Simon Slavin wrote: > > "Today, I?ll talk about why we stopped using serial integers for our primary > keys, and why we?re now extensively using Universally Unique IDs (or UUIDs) > almost everywhere.? Argh? seriously? tl;dr: don?t.

[sqlite] AUTOINC vs. UUIDs

Posting this not because I agree with it but because the subject has come up here a couple of times. "Today, I?ll talk about why we stopped using serial integers for our primary keys, and why

[sqlite] AUTOINC vs. UUIDs

. 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 ke

[sqlite] AUTOINC vs. UUIDs

e.org] On Behalf Of Simon Slavin > Sent: Wednesday, 20 May, 2015 14:38 > To: sqlite-users at mailinglists.sqlite.org > Subject: Re: [sqlite] AUTOINC vs. UUIDs > > > On 20 May 2015, at 8:52pm, Kees Nuyt wrote: > > > The autoincrement clause causes an entry in the sqlite_sequen

[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

[sqlite] AUTOINC vs. UUIDs

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. Sent from

[sqlite] AUTOINC vs. UUIDs

On 5/20/15, Scott Doctor wrote: > > Given a field that is a primary key with auto-increment, does sqlite > store an integer that gets incremented, or does it look at the last row > and increment its value? https://www.sqlite.org/autoinc.html -- D. Richard Hipp drh at sqlite.org

[sqlite] AUTOINC vs. UUIDs

I can see the issue. For instance, an invoice ID related to inventory, where the invoice ID is the PK number. Two salesmen on their iPads take an order where their local database assigns the same PK number. When merged you have two invoices with the same ID. Seems a classic problem with non

[sqlite] AUTOINC vs. UUIDs

Hmmm, 9,223,372,036,854,775,807. Disregarding the negative numbers because,... well... If your computer can process one billion completed, finalized, transactions per second (I want one of those computers), the pool of numbers will deplete in a mere: 9223372036854775807 / 10 ) /

[sqlite] AUTOINC vs. UUIDs

Given a field that is a primary key with auto-increment, does sqlite store an integer that gets incremented, or does it look at the last row and increment its value? Scott Doctor scott at scottdoctor.com On 5/20/2015 11:05 AM, Simon Slavin wrote: > Posting this not because I