>> говорит - что исполнение байт кода - всегда дольше чем просто поиск
>> по базе key-> value.
> Если обращения к KV store в inner loop - да, разница будет.
> Но обычно обращения к БД во внутренних циклах - крайне плохой
> тон, данные надо обрабатывать после запроса/выборки, а не вместе с оными.
> В остальных случаях накладные расходы будут несущественны.
> Не забывайте, что у KV обычно всё атомно плохо с индексацией и
> произвольным поиском. Плюсы от возможности вести поиск по связям и наборам
> полей могут и перевесить минусы от наличия разборщика запросов. Не везде,
> естественно.

Плохо с произвольным поиском по ключу?! а индексация там к чему?
А о словах secondary key - вы что-то слышали?

> Во всяком случае, Subversion уже использует SQLite в клиентской части. Очевидно, осознали
> плюсы.

Видимо это должно служить большим показателем.. Не подскажете почему? при этом у mysql был bdb сторадж. http://dev.mysql.com/doc/refman/5.0/en/bdb-storage-engine.html
но я не разу не слышал о SQLite сторадже для MySQL.
не подскажете почему?

>> Кстати как там с SQLite с поддержкой транзакционного стораджа?
> А там иных не бывает... огромная проблема SQLite - необходимость блокирования всего
> файла при записи.

ЭЭ.. позвольте - если там есть нормальные транзакции - то там не надо блокировать весь файл.
Так и запишем - транзакций нету.

> Коммиты у SQLite атомарные, поэтому с конзистентностью всё
> более-менее. Не хуже, чем у BDB, во всяком случае.

у BDB - можно делать комиты в несколько таблиц внутри одной транзакции без необходимости лочить базы.
Как видимо это явно "лучше".