>> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в
>> BDB ?
> Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В
> SQL-based движках в основном всё те же btree :) на подложке.

Замечена попытка ухода в сторону. Вами был выдвинут тезис что реализация KV стораджа средствами SQLite по меньшей мере не медленее чем  BDB а то и быстрее. Вот отсюда и вопрос - вы серьезно считаете что скорость выполнения предкопилированых sql запросов в sqlite будет дотягивать до скорости поиска по b-tree для BDB ?

> А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на
> большие расстояния. Да и просто практичнее в плане удобства. Доехать-то доедешь,
> но за@#$шься прилично.

Зависит от загруженности города. Я знаю много городов где на велосипеде доехать быстрее.

> Там, где структура данных достаточно простая, и отношение объема данных к объёму
> единственного ключа максимально - лучше KV не придумать. Где посложнее -
> использование KV или прямых методов доступа к сторейджу выльется в феерические
> костыли, которые уже давным-давно сделаны в реляционных движках, и сделаны лучше.

Может вы забыли что для правильного использования SQL надо приводить к НФ 3? а тогда большой разницы с поиском по ключу в KV не будет. хотя да.. современная молодежь забывает о нормальных формах БД.

> Вопрос в применимости. Когда-то embedded-движков RDB не было, и все юзали что
> попало, изобретая велосипеды для поиска в KV-сторейдже к примеру. Сейчас их
> вагон, и отказываться от удобства - тупо.

Да да. А перегружать задачи не нужной функционостью - это ооочень правильно. И терять в скорости тоже..
как это похоже на современных программистов - которые вырезают гланды автогеном..