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

Reply via email to