ОК, а какого рода действия выполнялись на БД? Т.е. на основании чего сделан такой вывод?

ограничение на 2 гига - файл, кажется у fat32

Lexander
ОК, а какого рода действия выполнялись на БД? Т.е. на основании чего сделан такой вывод?

Хм… Разработка… :-) Выборки там всякие… Даже не знаю, что на это ответить.
Скажем так: sqlite, это прекрасная простая база данных и я сам ни раз и ни два её использовал и ещё буду, но если данных много, то я люблю больше контроля. Например, возможность написания своих функций на PL/SQL… Всё-таки firebird, это полноценная RDBMS (не Postgres, конечно, но и не mysql, блин!), а sqlite – лишь правильно размеченный файл с библиотекой для удобного доступа к нему.

Плюсы такие:
1. Наличие встроенного процедурного языка;
2. Нормальная транзакционность – можно писать одновременно с нескольких потоков;
3. Расширяемость – например, можно легко перевести базу на серверную реализацию птички;
…В конце концов, она быстрее! :-) Ну хорошо, в общем среднем быстрее.

Минусы:
1. Сложнее sqlite'а;
2. Не настолько просто переносима, так как есть подводные камни – но всё решается малой кровью;
3. Одного питона не достаточно – нужны либы и обёртки.

ZZZ
Хм… Разработка… :-) Выборки там всякие… Даже не знаю, что на это ответить.

Я, собственно, прошу поделить опытом, чтобы учитывать его в будущих разработках.
Меня, в частности, интересовали типы операций, характер нагрузки, приблизительные соотношения разных типов, даже нюансы вроде описанных в скобках:
1) вставка (единичная, массовая, пакетами по Х штук)
2) редактирование (единичная, массовая по сложным/простым условиям)
3) чтение (сложность запросов, объем выборок и пр.).
на вашей базе конкретного размера, размещенной на конкретном носителе(-ях) с известными конкретными параметрами быстродействия.

Вот, например, указанная возможность написания своих функций - очень хороший аргумент. Но только не для встраиваемой СУБД, т.к. в этом случае нет необходимости (и преимущества) в централизованном хранилище таких объектов. Достаточно поддержки транзакций.
А вот с расширяемостью я соглашусь. Хотя тут тоже не все так просто. Ведь нечасто требуется предусмотреть переход на сетевую СУБД со встраиваемой - задачи совсем разные. Таким образом, этот аргумент следует учитывать на стадии проектирования после сбора требований к продукту.

ZZZ
Нормальная транзакционность – можно писать одновременно с нескольких потоков;

Я для работы с sqlite вообще использую отдельный класс с очередью запросов, поэтому таких проблем нет. А вот использование sqlite несколькими процессами действительно требует костыля, от которого я бы отказался в пользу полноценной сетевой СУБД (пусть даже она используется только локально).

Lexander

ZZZ
Нормальная транзакционность – можно писать одновременно с нескольких потоков;

… А вот использование sqlite несколькими процессами действительно требует костыля, от которого я бы отказался в пользу полноценной сетевой СУБД (пусть даже она используется только локально).

не знаю как в остальных ос, а в linux sqlite нормально пашет при записи от нескольких процессов, при изменении данных происходит локирование базы.

Да все нормально вроде бы даже на Вин.
Но раз в доке написано, что не рекомендуется, то в продакшн при интенсивных вставках в большую базу на NFS я такой режим не использовал бы, если бы не был на 100% уверен в нормальной поддержке локов на этой конкретной NFS. Исходя исключительно из этой рекомендации.
Как обычно, можно, только осторожно :)
Если приходится переносить базу на сетевое хранилище - это одно дело, если же изначально известнен режим работы, характерный для сетевых СУБД, то, имхо, стоит использовать для этого полноценную сетевую СУБД.

ЗЫ
В одном проекте, не связанном с sqlite, но использующем файловые блокировки под Вин ХП СП2 я лично сталкивался с проблемами, когда установленная блокировка не снималась. Приложение было расчитано на круглосуточную работу и такой неприятный баг был очень некстати.

У меня опыт работы с sqlite крайне отрицательный. Проект начинался с использованием django+sqlite, потом путем замены в settings.py sqlite на mysql(кстати, mysql был на другом хосте) производительность приложения выросла в несколько раз. Пришли к выводу, что это нельзя использовать, если происходит интенсивная запись в базу. С чтением оно еще туда-сюда справлялось.

Lexander
Меня, в частности, интересовали типы операций, характер нагрузки, приблизительные соотношения разных типов, даже нюансы вроде описанных в скобках:

Я понимаю, что тебе надо, но ответить на это не могу. Просто общее субъективное ощущение тормознутости sqlite меня не оставляет.

Lexander
Вот, например, указанная возможность написания своих функций - очень хороший аргумент. Но только не для встраиваемой СУБД, т.к. в этом случае нет необходимости (и преимущества) в централизованном хранилище таких объектов.

Не соглашусь. Это удобно.

Lexander
Ведь нечасто требуется предусмотреть переход на сетевую СУБД со встраиваемой - задачи совсем разные.

Мне лично не приходилось, но сталкивался с приложением, которое умело работать как локально, так и как клиент-сервер. Лично мне очень понравилась идея архитектуры. Хотя там такая фирма была… И такие “программисты”… Страшно вспоминать…
Там был движок и фронтенд – очень красиво.

Lexander
Я для работы с sqlite вообще использую отдельный класс с очередью запросов, поэтому таких проблем нет.

Я думаю, что все рано или поздно приходят к этому. :-)
И это костыль.

Ed
Пришли к выводу, что это нельзя использовать, если происходит интенсивная запись в базу.

Так оно и есть. Если нужен portable вариант базы с лучшим быстродействием – опять же файрбёрд.

Ed
Пришли к выводу, что это нельзя использовать, если происходит интенсивная запись в базу

О, уже что-то.
А поподробнее можно?

ZZZ
Не соглашусь. Это удобно.

В чем удобство выражается?
Надеюсь, не только принципе: вся логика в одном месте?

ZZZ
И это костыль.

Не совсем. Одноногий ходит с костылем, т.к. без костыля ходить не может, это замена ноги.
Костыль - это если по другому никак. Выделить всю работу с СУБД в отдельный класс - это просто удобство работы с кодом, сопровождения и т.п., но никак не замена безальтернативе.

Lexander
чем удобство выражается?
Надеюсь, не только принципе: вся логика в одном месте?

Быстрее питьоньего кода. Иногда очень важно оптимизировать работу с базой, когда она является узким местом.
Конечно не стоит делать из БД контроллер.

Lexander
Не совсем. Одноногий ходит с костылем, т.к. без костыля ходить не может, это замена ноги.
Костыль - это если по другому никак. Выделить всю работу с СУБД в отдельный класс - это просто удобство работы с кодом, сопровождения и т.п., но никак не замена безальтернативе.

Ээээ… Нет. Самое главное тут то, что запросы к базе синхронны, а вот траблы при несинхронных изменениях известны – лично я сталкивался с повреждениями базы при множественных инсертах в несколько потоков (но там было всё сложно и я решил перейти на постгри).

Lexander
Выделить всю работу с СУБД в отдельный класс - это просто удобство работы с кодом, сопровождения и т.п.

А как же ORM? :-)