sqlite3 doesnt have a builtin UUID function, but all thats needed is a randomish blob.
For example:
external_id text default (hex(randomblob(16)))
Since this might be used as a search field, it should be indexed:
drop table if exists Foo;
drop index if exists foo_xid;
create table Foo (
external_id text default (hex(randomblob(16)))
);
create index foo_xid on Foo (
xid
);
Benchmarking shows this has good performance. For one million records, using sql and a command line like:
time sqlite3 benchmark.db < 01-test.sql > /dev/null
testing with sql like:
select 1
from
Foo f
join Bing b on f.id = b.id;
;
Times reported by time:
| join on | real | user | sys |
|---|---|---|---|
| integer primary key | 0m2.325s | 0m1.209s | 0m1.116s |
| unindexed 16 bytes of text | 0m8.290s | 0m4.331s | 0m3.957s |
| indexed 16 bytes of text | 0m0.547s | 0m0.514s | 0m0.033s |
These numbers are consistent across several runs. Note the indexed text has surprising results.
Its consistently several times faster than an integer field. I can see this becomming a rabbit hole.