После двух лет разработки представлен (http://www.sqlite.org/releaselog/3_7_0.html) релиз новой ветки SQLite 3.7.0, легковесной базы данных, оформленной в виде подключаемой библиотеки.
Код SQLite переведен в разряд общественного достояния (public domain), т.е. может использоваться без ограничений и безвозмездно в любых целях. Финансовую поддержку разработчиков SQLite осуществляет специально созданный консорциум, в которых входят такие компании, как Adobe, Oracle, Mozilla, Symbian и Bloomberg.
Наиболее значительным улучшением в новой ветке является реализация журнала транзакций (WAL-лог, Write-Ahead Logs) в котором отражаются все происходящие с базой данных события, связанные с изменением данных и схемы их хранения. Ведение WAL-лога существенно повышает надежность хранения данных, гарантирует атомарность выполнения транзакций, дает возможность организовать откат изменений на определенное состояние в прошлом и позволяет организовать такие сервисные возможности, как горячее резерв...URL: http://www.sqlite.org/releaselog/3_7_0.html
Новость: http://www.opennet.me/opennews/art.shtml?num=27388
http://sqlite.org/src/stat
sqlite всё жирнеет :)
Странная какая-то фича - и файлов БД становится не один, и проблем с ней есть. На любителя весьма, судя по описанию. При том любитель должен желать много и часто писать в базу (много таких любителей?) и мириться с чуть более тормозным чтением и уймой потенциальных грабель.
И зачем оно в SQLite? Они бы еще триггеры и ХП реализовали.
Так частично же тригеры там уже есть. http://www.sqlite.org/lang_createtrigger.html
Например они создаются когда внешние ключи делаешь с каскадами.
Триггеры просто есть, а не "частично" (включая триггеры на VIEW). А внешние ключи триггеров никаких не создают, см. http://www.sqlite.org/foreignkeys.html
Спорить не будем. Не забываем про genfkey который и создает совокупность тригеров для внешних ключей.http://www.sqlite.org/faq.html#q22
http://www.sqlite.org/cvstrac/fileview?f=sqlite/tool/genfkey...А про полноценность триггеров в sqlite это совершенно отдельная беседа.
точно genfkey убрали ж в версии 3.6.23, только пока в стабильных ветках дистров более старые версии где он все еще есть
Обожаю SQLite. Это просто конфетка
SQLite на мобильных устройствах незаменим.
Чуть больше года назад пытался использовать SQLite для хранения данных в ПО на Windows Mobile. К сожалению, все прекрасно работало (простейший тест: создать базу → записать → прочитать → закрыть) на внутренней памяти устройства, а вот если писать на внешнюю SD - валился.
У нас работает в продакшене лет 5 на нескольких десятках винмобайловских КПК, ни с одной версией эскулайт проблем не было. А если _у вас_ валился, то однозначно, RTFM.
> Финансовую поддержку разработчиков SQLite осуществляет
> специально созданный консорциумНа самом деле, это лишь клиенты платной техподдержки эскулайт (кажется, 75 000$ в год все удовольствие стоит без ограничения на число инсталляций; как недавно представители Оракл в рассылке эскулайта писали, это очень выгодно и удобно, так что mush have). "Консорциум" слово красивое, а эскулайт развивается по запросам комьюнити.
> "Ведение WAL-лога существенно повышает надежность хранения данных,
Неправда. Надежность - не повышает, с надежностью в эскулайт и раньше все в порядке было.
> гарантирует атомарность выполнения транзакций
Транзакции всегда атомарны, иначе это не транзакции.
> организовать откат изменений на определенное состояние в прошлом."
На "определенное состояние" откат не делается, по крайней мере, сейчас. Можно только последнюю транзакцию откатить. Теоретически как бы можно было б сделать откат не только последней транзакции, но вместо этого реализованы автоматические чекпойнты и чекпойнты в фоновом потоке. Приложение может заблокировать чекпойнты насовсем, так что журнал будет только расти и можно состряпать утилиту для отката, но ротации журнала нет, так что это будет странный ковыляющий велосипед. Хинт: есть встроенная фича логирования запросов, если нужна история изменений, самое то.
Мож я чё в инглише не понимаю, поправьте?> Advantages include:
> 1. WAL is significantly faster in most scenarios.
> 2. readers do not block writers and a writer does not block readersи тут же:
> But there are also disadvantages: 6. WAL might be very slightly slower (perhaps 1% or 2% slower) than the traditional rollback-journal approach in applications that do mostly reads and seldom write.Разве "большинство чтений, изредка запись" не является "most scenarios"?? (биллинг/банкинг не учитывем) Тем более, что теперь ридеры и врайтеры как бы не мешают друг другу. Чудеса...
Все верно написано. Для чтения режим WAL чуть медленнее, т.к. надо при чтении заглянуть и в WAL журнал, где могут быть новые версии данных, еще не внесенные в файл БД. Поэтому, если в приложении в основном чтение производится, чтение будет на пару процентов медленнее. При малом числе операций записи (на 1 запрос записи порядка 1000 и выше запросов чтения, почти или полностью read-only БД) и усредненное время всех запросов станет на 1%-2% больше, хотя запись с WAL работает быстрее. Если же запросов записи порядка единиц процентов и более от общего числа обращений к БД (что и обозначено в оригинале как наиболее типичный случай), будет заметен выигрыш от использования WAL.
Клевый проект. Использовал года 2 назад эту БД, остались очень теплые чувства. Все делается очень просто и надежно, хорошая документация. Не без ложки дегтя конечно: на обработке миллионов записей что-то случалось, и запрос не завершался, даже спустя 20-30 минут, что для того проекта было неприемлемо. К счастью, такой сценарий был маловероятен. Наверное мне скажут, что sqlite на таких объемах был не к месту; я даже соглашусь :). Просто была необходима самая маленькая, встроенная в приложение БД.
> Наверное мне скажут, что sqlite на таких объемах был не к месту; я даже соглашусь :)А мы-то не знали, для баз в десятки миллионов и более записей используем ;-) Вот около 500 миллионов записей в модуле полнотекстового поиска проблемка была, а так порядок :-)
>А мы-то не знали, для баз в десятки миллионов и более записей
>используем ;-) Вот около 500 миллионов записей в модуле полнотекстового поиска
>проблемка была, а так порядок :-)У меня там довольно тяжелый GROUP BY был. С фильтрами и сортировкой. Наверное из-за него все колом вставало.