SQLite в многопользовательской среде

[Андрей Варкентин]

Привет, форумчане!

Хочется/необходимо написать небольшую учетную систему, в которой один пользователь наполняет базу и два-три человека строят на базе этих данных отчеты. Не будут ли проблемы в работе при использование СУБД SQLite? Возможно ли организовать комфортную работу клиентам? Сеть - обычная локальная одноранговая. Почему SQlite - не спрашивайте, нравится!

[Ism]

Проблемы будут, SQLite рассчитан на одного пользователя, хотя может кажется со многими. Замена - Firebird - то же самое , но работает и в embedded и в серверном режиме

[amateur]

по идее нет, но при вашей схеме: работает 1 пользователь, а другие смотрят. А комфорт от Вас зависит

с несколькими пользователями sqlite работает...

[debi12345]

Проблемы будут, SQLite рассчитан на одного пользователя, хотя может кажется со многими

Если возможна однвоременная запись и файловая система не поддрживает автоблокирвку файлов БД при записи в них (как это умеет например Netware), то лучше написать над SQlite3 приемщик+диспетчер запросов. Если автоблокирвка файлов есть - то нкакх проблоем для многоих поьзователей, кроме равзе что лочки файла дл всех при слете записи от одного.

[Ism]

Все это садомазохизм, sqlite не создана для многопользовательской работы

[debi12345]

sqlite не создана для многопользовательской работы

Как и Clipper|FoxPro - но на этих СУБД написано множдество многопользователських (сотни пользователей !) программ, нужен лишь механизм блокировки файлов БД для предотвращения одновремнной записи.

[Максим]

Какой смысл извращаться при наличии вменяемых мощных инструментов?

[Kitayets]

плюсую Максиму - нужно брать уже готовый вариант многопользовательской базы, тут много вариантов и не одного повода тащить на эту задачу sqlite.

[stikriz]

FireBird

[Nik]

В теории SQLite может работать с несколькими пользователями одновременно, но на практике я бы не рисковал, если данные дороги. Берите MySQL или что-то подобное.

[debi12345]

Какой смысл извращаться при наличии вменяемых мощных инструментов?

Тяжеловесность этой мощи
Вы наверно не писали проги под SQlite3 - 1) не надо вообще ничего настраивать, возиться с установокой и созданием БД и пользователей 2) все "летает" - не то слово 3) практически невозможно убить БД (в реЖиме WAL- мне удалось только с 15-го (!) выключения света при вставке полмиллиона записей в одной транзакции - ставил эксперимент на живучесть, и то "убить" удалось только шифрованный вариант SQLITE, обычный не "убьешь"), 4) из-за мизерного размера БД может бэкапиться хоть каждый запуск, 5) таблицы можно "раскидать" по отдельным файлам (что резко повышает живучесть, да и скорость выборки) и объдинять в одну вирутальную БД на этапе коннекта (команда ATTACH)...

Кстати, в SQlite3 уже год как поддрживаются несколько одновременных транзакций на БД, хотя с обрастанием фишками сама DLL стала уже не совсем "лайт".

[stikriz]

1) не надо вообще ничего настраивать, возиться с установокой и созданием БД и пользователей

Embeded FireBird - то же самое, но это уже не многопользовательский режим.

2) все "летает" - не то слово 3)

FireBird - смотря что там надо. Есть-ли триггеры? Сколько, какие вьюшки, сортировки по индексам? и т.д. и т.п

3) практически невозможно убить БД

Про Абрамс слышали ? Бакап, бакап и только бакап - это единственно верное решение всех времен и народов, но это не говорит, что FireBird сам по себе ненадежен - там все нормально, пока винда не испортит файл базы, но это другая песня.

4) из-за мизерного размера БД может бэкапиться хоть каждый запуск,

FireBird очень компактно хранит данные. Если у Вас база маленькая, то тоже бакапьте при запуске.

5) таблицы можно "раскидать" по отдельным файлам (что резко повышает живучесть, да и скорость выборки)

Очень спорно. Живучесть точно понижает. Скорость тоже понижает, когда файлов становится много.

Явные преимущества FireBird, например (т.е. вменяемой СУБД): это сервис, а значит прямого доступа к файлу БД не надо - все работают по сети, мноооого пользовательская работа, процедуры, вьюшки, транзакции+версионность. А так же, навыки работы с стандартным SQL сервером, которые пригодятся обязательно.
Отличная дока: http://www.ibase.ru/develop.htm

Есть еще Постгресс, но это немного сложнее.

[debi12345]

FireBird - смотря что там надо. Есть-ли триггеры? Сколько, какие вьюшки, сортировки по индексам? и т.д. и т.п

Все это есть в SQLITE3. Есть даже язык для написания БД-функций и процедур (если не хочется заморачиваться с написанием оных на "С").

Живучесть точно понижает.

Нет, если хранить рид-онли справочную инфу в одном файле, а активно записываемую - раскидать по разным файлам в завимости от задачи. В самом худшем сценарии крэша "убивается" инфа только одной задачи.

Скорость тоже понижает, когда файлов становится много.

Скорость выборки из БД зависит не от количества файлов(если их конечно не тысячи - что нереально для расматирваемой задачи), а от их размера - начиная с какого-то порогового размера БД-файл перестает помещаться в кэш файловой системы и, чтобы прочитать весь файл - головкам диска, с их латентностью 20+ ms приходится побегать по поверхности, собирая весь этот файл (для борьбы именно с этим эффектом и презназначены БД-индексы - они до минимума сужают область бегания головок ).

ПС:
Не спорю, что "птичка" - супервещь, но SQLITE3 вообще поражает воображение Такой малыш даже BLOB-ы умеет хранить, никаких проблем с юникодом, с датами, с NUMERIC (арифметика без потери точности),.. !

Добавлено спустя 7 минут 14 секунд:
Да, забыл особо подчеркнуть наличие версии с шифрованными файлами БД (оная используется например в IPhone & Co... - здесь я так понял, SQLIT3 нашла свою очень жирную нишу). Аналогов подобного (шифрования именно файлов, а не отдельных полей) нет ни в какой другой БД.

[stikriz]

Нет, если хранить рид-онли справочную инфу в одном файле, а активно записываемую - раскидать по разным файлам в завимости от задачи.

Ну, и остались мы со справочной информацией... Что толку? База все равно сдохла, для дальнейшей работы негодится. Все наши данные попорчены.

а от их размера - начиная с какого-то порогового размера БД-файл перестает помещаться в кэш файловой системы и, чтобы прочитать весь файл - головкам диска, с их латентностью 20+ ms приходится побегать по поверхности, собирая весь этот файл (для борьбы именно с этим эффектом и презназначены БД-индексы - они до минимума сужают область бегания головок ).

Кэш файловой системы ~ 64 Кб. Что толку говорить о неком кэше файловой системы? Пратически никогда база там не помещается. В СУБД используется совсем другое кэширование. Кэширование объектов базы, а не некого файла. И если база небольшая, то все там помещается. Тем более про индексы говорить не надо - в FireBird все в порядке с индексами.

Такой малыш даже BLOB-ы умеет хранить, никаких проблем с юникодом, с датами, с NUMERIC (арифметика без потери точности),.. !

Поверьте, что вот такие восторги по поводу обычных обыденных решений наводит на мысль, что с "птичкой" Вы просто незнакомы. Одновременно, что SQLLit_у больше похвастаться нечем? Когда-то давно разработчики Постгресс восторженно сообщили, что работа с базой в каком-то там режиме ускорилась в 200 раз... На что в конфе InterBase задумались, мол, а много-ли там еще таких хреновых алгоритмов осталось, ну, которые можно ускорить в 200 раз?

Я же не спорю, тем более, не хочу говорить, что SQLLite использовать не надо. Просто, я думаю, что всегда лучше использовать полноценную СУБД. А из полноценных СУБД FireBird самый маленький+бесплатный+легко администрируемый и устанавливаемый. К тому же, он позволяет расти проекту, т.к. имеет довольно большой запас по масштабируемости, размеру базы и к-ва пользователей. К тому же, он развивается очень активно. Много хорошей доки, есть сообщество и т.д. и т.п.

Добавлено спустя 18 минут 20 секунд:

Аналогов подобного (шифрования именно файлов, а не отдельных полей) нет ни в какой другой БД.

В InterBase есть.

[debi12345]

Ну, и остались мы со справочной информацией... Что толку? База все равно сдохла, для дальнейшей работы негодится. Все наши данные попорчены.

В этом случае делается автоматический бэкап файлов оперативных таблиц при старте программы. Пару раз (на старых - менее надежных версиях SQLITE3) выручило после "дергания" электричества и ошибок операторов (вбили не те данные).

Кэш файловой системы ~ 64 Кб

Это скорее единица дробления кэша. Насчет целого кэша "FREE" в Линуксе дает совсем другие цифры. Десятки и даже сотни мегабайт.

К тому же, он позволяет расти проекту, т.к. имеет довольно большой запас по масштабируемости, размеру базы и к-ва пользователей.

100%. Позволяет безболезненно проапгрэйдиться до сетевой версии - в этом случае однозначно предпочтение "птичке". С другой стороны, если нужны фишки из разряда ORACLE (процедурные языки, блокировки на уровне отдельных записей,..) - можно стразу ставить PostgreSQL в режиме локального сервера с репликацией "наверх" (так сделано у нас в "конторе" - но мучаемся с падениями баз из-за плохого электричества - порядка 10..15 "вытаскиваний" данных в месяц при примерно 200 рабочих не-UPSованных мест). С SQLITE3 имели проблему с целостностью файлов БД всего однажды за примерно 4года на 4 рабочих местах.

Добавлено спустя 7 минут 10 секунд:

Постгресс восторженно сообщили, что работа с базой в каком-то там режиме ускорилась в 200 раз... На что в конфе InterBase задумались, мол, а много-ли там еще таких хреновых алгоритмов осталось,

Знаю этот режим - оператор "NOT IN" (он по сути есть множество "OR", которые традиционно плохо оптимизируются). Решалось сложным по синтаксису (и отжирающим память) трюком с применением LEFT OUTER JOIN и отфильтровкой несовпавших - возможно включили это решение в мэйнстрим. Еще..добавили автоматичкий HASH_JOIN (можно сказать автоиндекс) на строковых WHERE - тоже огромное ускорение... Это не плохие "алгортимы" - это чрезвычайная мозго- и трудоемкость оптимизации, всему свое время..