>> ты серьезно считаешь что SQL работает быстрее чем разные варианты B-Tree в
>> BDB ?
> Я серьезно считаю, что ты путаешь метод доступа и метод хранения. В
> SQL-based движках в основном всё те же btree :) на подложке. Замечена попытка ухода в сторону. Вами был выдвинут тезис что реализация KV стораджа средствами SQLite по меньшей мере не медленее чем BDB а то и быстрее. Вот отсюда и вопрос - вы серьезно считаете что скорость выполнения предкопилированых sql запросов в sqlite будет дотягивать до скорости поиска по b-tree для BDB ?
> А еще я серьезно считаю, что автомобиль практичнее велосипеда при поездках на
> большие расстояния. Да и просто практичнее в плане удобства. Доехать-то доедешь,
> но за@#$шься прилично.
Зависит от загруженности города. Я знаю много городов где на велосипеде доехать быстрее.
> Там, где структура данных достаточно простая, и отношение объема данных к объёму
> единственного ключа максимально - лучше KV не придумать. Где посложнее -
> использование KV или прямых методов доступа к сторейджу выльется в феерические
> костыли, которые уже давным-давно сделаны в реляционных движках, и сделаны лучше.
Может вы забыли что для правильного использования SQL надо приводить к НФ 3? а тогда большой разницы с поиском по ключу в KV не будет. хотя да.. современная молодежь забывает о нормальных формах БД.
> Вопрос в применимости. Когда-то embedded-движков RDB не было, и все юзали что
> попало, изобретая велосипеды для поиска в KV-сторейдже к примеру. Сейчас их
> вагон, и отказываться от удобства - тупо.
Да да. А перегружать задачи не нужной функционостью - это ооочень правильно. И терять в скорости тоже..
как это похоже на современных программистов - которые вырезают гланды автогеном..
