metosПроектирую некое хранилище данных (для большого количества записей).
Есть некие объекты, которых может быть очень много (до 5 миллионов). В этой БД будет содержаться информация для каждого из объектов. Каждый объект идентифицируется по его уникальному глобальному GUID (16 байтов), т.к. таких БД может быть несколько и возможен импорт данных из одной в другую.

Так вот изначально проектировали под СУБД (MySQL/MSSQL) и соответсвенно планировани хранить в таблице объектов глобальный GUID и внутренний ID (INT 32 / INT 64). Но сейчаз решили что функций SQLite вполне достаточно.
Тип GUID будет представлен как BLOB в 16 байт.
И вот у меня появилось 3 возможных решения:
1) оставить в таблице объектов глобальный GUID и внутренний ID (индексы только для ID);
2) использовать в БД только GUID (индексы только по нему);
3) использовать в БД только GUID, но представленнный в виде двух полей типа INTEGER (индекс по обоим полям).

Какой вариант оптимальнее для SQLite?


Исходите из отношения таблиц.
GUID нужен только для внешней связки при импорте/экспорте и не используется приложением? Тогда лучше вообще храните его в отдельной таблице, а для связки используйте INTEGER PRIMARY KEY - это в SQLite самый оптимальный индекс ( http://sqlite.org/lang_createtable.html#rowid). Только учтите, что PK в SQLite не подразумевает NOT NULL - последний нужно определять явно.

metosИ ещё 3 тупых вопроса:
Правильно ли я понимаю, что значения полей типа INTEGER в DB-файле будет преставлено в виде ANSI-строк?
Правильно ли я понимаю, что значения полей типа BLOB в DB-файле будет преставлено в виде UTF-8 строки?
Имеет ли какое то значение тип поля при создании для него индекса?

1. Нет. В SQLite столбцы не типизированные, неявного приведения типов нет: что занесете, то и будет хранить. Хранимые типы описаны в мануале: http://sqlite.org/datatype3.html
2. Нет. См. ссылку выше.
3. Имеет. Индекс как раз типизирован (иначе и быть не могло). Чем короче индекс, тем быстрее поиск.

metos,

Если в запросе одна таблица, то адресовать напрямую по GUID будет оптимальнее, чем искать GUID по одной таблице, а потом по другой искать по INTEGER.

Если в запросе несколько таблиц и вы их будете связывать по GUID, то однозначно INTEGER лучше. Да и работать с целыми удобнее, чем с BLOB.