Оптимальный по скорости выборки и объему вариант таблицы - обычная с ROWID или WITHOUT ROWID?

Из инфы по SQLite вынес,
что если есть возможность сделать первичный ключ таблицы целочисленным, то это хорошо - его можно определить известным способом и он станет псевдонимом ROWID.
Тогда поиск по этому нашему первичному ключу будет идти быстро, поскольку данные будут по нему кластеризированы. То есть, будут физически храниться на диске упорядоченными по значению нашего ключа, поскольку он псевдоним ROWID, а данные в SQLite хранятся упорядоченными по ROWID (по внутреннему индексу). Если это не таблица WITHOUT ROWID.
При этом, помимо ожидаемого быстрого поиска будет и экономия объема в силу того, что, если таблица с ROWID, то данные хранятся в B+ дереве, а не в B дереве (как в таблице WITHOUT ROWID). Отлично!
Но!
Читаю в одном популярном блоге прямо противоположную рекомендацию, имею ввиду прежде всего пункт №2, но и остальные тоже...:

Из-за особенностей работы таблиц WITHOUT ROWID, разработчики SQLite рекомендуют использовать такие таблицы в тех случаях, когда: 1. Вы используете составные первичные ключи или когда первичный ключ не является целым числом, а имеет другой тип данных. 2. Если вам нужно повысить скорость работы таблицы с первичным ключом INTEGER, создавайте таблицу без внутреннего индекса, этим вы ускорите выборку и уменьшите объем базы данных. Если таблицы имеет индекс ROWID и индекс в виде INTEGER PRIMARY KEY, то SQLIte делает перебор двумя циклами: первый цикл идет по столбцу ROWID, второй цикл идет по столбцу INTEGER PRIMARY KEY, хотя значения этих столбцов совпадают. 3. Если в таблицах хранятся строки с малыми значениями, то таблицы без индекса (WITHOUT ROWID) будут работать несколько быстрее, чем со столбцом ROWID.

То есть, согласно пункту 2 рекомендуют использовать таблицу WITHOUT ROWID.
У меня есть версия, что эти рекомендации нужно понимать так. Если "в таблицах хранятся строки с малыми значениями", то большого преимущества B+ дерева перед просто B деревом нет. И тогда вступают в силу факторы дополнительных издержек, связанных с наличием внутреннего индекса по ROWID и вот этот упомянутый "двойной поиск" (на самом деле не знаю, будет ли реально поиск двойным, для случая, когда целочисленный первичный ключ является псевдонимом? Есть сомнения, может быть в этом блоге автор ошибся?).
Если это так, то каков критерий того, что строка таблицы имеет "малое значение"? Это эквивалентно тому, что в таблице много строк? Или что-то ещё?
Поясню.
Меня интересует случай, когда имеется таблица с очень большим числом строк (порядка нескольких сот миллионов). Первичный ключ планирую сделать целочисленным - его значение будет генериться в коде (для этого перевожу набор целочисленных и текстовых значений в целочисленные - о своему алгоритму).
И тут не понятно, то ли использовать первичный ключ как псевдоним ROWID, то ли делать таблицу без ROWID, чтобы индекс по моему первичному целочисленному ключу был кластеризированным (но в этом случае будет B дерево, а не B+ дерево). Пытаюсь соптимизировать в первую очередь скорость выборки по первичному ключу. Объем - тоже, но во вторую очередь.
P.S. То ли вообще сделать таблицу WITHOUT ROWID и использовать составной первичный ключ из набора столбцов типа INTEGER и TEXT.
Вот тут полезная информация, но местами противоречит процитированному блогу. Только что нашел её, пока писал вопрос))) Не успел просмотреть подробно.
Таки чему верить? Как быть?

Добавлено через 7 минут
Увидел сейчас, что есть такой критерий - если размер строки меньше 1/20 страницы, то строка маленькая по размеру. Для стандартной страницы в 1024 байта это всего 50 байт. Не много. У меня примерно 50 байт и будет) Может чуть меньше)

Добавлено через 3 минуты
Вообще, такое ощущение, что для лучшего соответствия стандартам SQL и следовательно для уменьшения возможной головной боли нужно использовать WITHOUT ROWID и STRICT (последнее уж точно). Ну, это с учетом того, что WITHOUT ROWID несколько ограничивает возможности - например, в них нельзя использовать некоторый функционал для типа BLOB.

0