BDB vs SQLite

как у BDB сейчас с поддержкой SQL?

если под BDB вы имеете ввиду BerkeleyDB, то с SQL там как и раньше, без изменений. Вот уже много лет :)

Ты не прав, SQL там уже есть :)

Сравнил жигуль с броневиком. Скажи какую задачу решаешь. Сколько данных будешь хранить, какое количество запросов будет, нужна ли транзакционность, надежность, репликации ... ?

SQL в беркли сделан «SQL API by incorporating SQLite»

А кто тут броневик и жигуль?

Очевидно, что жигуль это sqlite :)

а berkeley db - велосипед без сидушки

Объем данных не больше гига, количество запросов небольшое , так как десктоп приложение

транзакционность весьма желательна

Ты не прав, SQL там уже есть :)

вот ведь блин..даже на сайт Oracle пошёл посмотреть - как и какое подмножество SQL они зацепили к key-value базе. Оказалось всё проще - их «SQL интерфейс BDB» просто другая база (с другой моделью) сделанная поверх. Обычный SQLite, c парой фирменных вкусных примочек.

Ну это как посмотреть. Для меня работает, правда я его пользую просто как контейнер для блобов.

sqlite работает на небольших объемах данных. И опять же, как в sqlite принято бороться с порчей базы при segfault'е/некорректном завершении приложения/выдергивании шнура питания ... ? Какой-нибудь более человеческий способ кроме dump'а уцелевшей части базы уже изобрели?

В общем, мне в такой базе было бы стремно хранить что-то кроме настроек приложения или данных, которые не жалко потерять.

sqlite работает на небольших объемах данных

Нормально sqlite работает. sqlite работает при непараллельном доступе к БД и с относительно простыми запросами (т.к. оптимизатор запросов там относительно простой).

И опять же, как в sqlite принято бороться с порчей базы при segfault'е/некорректном завершении приложения/выдергивании шнура питания ... ? Какой-нибудь более человеческий способ кроме dump'а уцелевшей части базы уже изобрели?

В sqlite вполне используется журналирование ровно для этой цели.

И опять же, как в sqlite принято бороться с порчей базы при segfault'е/некорректном завершении приложения/выдергивании шнура питания ... ? Какой-нибудь более человеческий способ кроме dump'а уцелевшей части базы уже изобрели?

В sqlite вполне используется журналирование ровно для этой цели.

Если включить synchronous=full, то sqlite работает очень медленно. А если не включать, то ... много раз получал покаррапченную БД путем выдергивания питания.

ога, bdb в режиме мастер-слейв репликации на трех машинках с включенной опцией DB_TXN_NOSYNC рулит нипадеццки. во-первых, всё летает, а во-вторых, надежно и без потерь данных.