On Thu, Nov 30, 2017 at 11:52 AM, Keith Medcalf <kmedc...@dessus.com> wrote:
> > On Thursday, 30 November, 2017 09:27, J Decker <d3c...@gmail.com> wrote: > > >> UUIDs are nice though if you don't have a natural key available and > >> you are generating keys on multiple systems. Sadly, they are strings > >> in sqlite, and it would be more efficient to store and compare them > >> as their 128-bit representation. Is there an extension that can do > >> that? > > Just store them as a 16-byte blob. What's the problem? > > >I would also like to make a note, that many criticisms are 'there's > >so many bytes to have to compare', however, because of the highly > >random nature of good UUIDs failure occurs quickly, usually within > >4 bytes, which makes it almost as good as an integer > > Or just use randomblob(16) ... > The problem with that is continual reformatting > > >(especialy for things like SQLite that are comparing numbers as > >strings anyway).... the only time the full thing is compared is > >on the row that exactly matches. > > I do not know what version of SQLite3 you are using, but according > to the source code, only strings are compared as strings. Everything > else is compared using the appropriate Affinity -- Double to Double, > Integer to Integer, BLOB to BLOB, etc. > Hmm; I thought it did store numbers as binary; but over the years of watching various messages on this list, I got the idea that numbers were being stored as strings also and haven't double checked.... my bad. Maybe it something about dates... > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
