Сержmrbrooks,

1) По умолчанию размер записи в sqlite 1 МБ. Или картинка должна быть меньше 1МБ или пересобирать dll.


Обманываете. Смотрим http://www.sqlite.org/limits.html

mrbrooksПрочитал холивар по поводу хранения изображений в БД в виде blob на сайте. Но там речь идет о таком монстре как ms sql server. А как быть с sqlite. К примеру уже имеется изображений почти на 500 Mb. Сейчас в БД у меня хранится ссылка на картинку. Или рациональней все же запихать их в blob?

Какие ваши мнения?

Зависит от ситуации. Если картинки более 16 кБ каждая, лучше на диске, если меньше, можно настроить размер страницы БД и хранить в ней. Если у вас ФС ext3, то можно хранить на диске, а если что-то из виндовых - лучше хранить в БД. Если у вас высокая интенсивность обновления, лучше на диске, иначе база может оказаться [почти] непрерывно залочена. Что касается производительности - тестировал хранение 100 миллионов картинок размером 1 кБ (превью) в базе, получил базу на 100 Гб, все ок. Разумеется, в таблице должно быть только одно поле - сам blob, всю остальную инфу необходимо хранить в другой таблице/таблицах (это нужно для обеспечения высокого быстродействия).

mrbrooksMBG,
картинки в среднем от 300 до 600 кб.
ось - винда.
обновление - если только при редактировании записи.

что посоветуете? =)

Я бы хранил в эскулайт базе. Виндовые ФС это что-то с чем-то, не зря гугл эф и многие другие приложения используют именно единый файл собственного формата для хранения изображений. Хранить, например, так:

create table photo (
id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
body blob
);

CREATE TABLE photo_meta
(
id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL,
save_date REAL,
delete_date REAL,
user_id integer NOT NULL,
name text collate russian NOT NULL,
size integer NOT NULL DEFAULT 0,
checksum text NOT NULL DEFAULT ''
);

Т.к. СУБД у нас с построчным хранением, то извлечение любого поля требует прочитать всю строку целиком, так что, если хранить блобы вместе с описанием файлов, то любые операции с такой таблицей станут очень неэффективны. Разумеется, в приведенном выше варианте значения поля id должны совпадать в обеих таблицах. Ключевое поле определено так, что идентификатор не может повторяться, даже если соотвествующая запись была удалена из таблицы - это удобно для репликации и восстановления случайно удаленного из дампов; если вам это не нужно, то можно чуть ускорить вставку, отказавшись от уникальности ключа. Поле delete_date позволяет вместо физического удаления просто помечать записи как удаленные, их можно легко восстановить.

Эскулайт поддерживает incrblob API, позволяющие потоково работать с блобами, но в вашей задаче вряд ли это нужно. Впрочем, см. http://sqlite.org/tclsqlite.html#incrblob и сишный интерфейс.

mrbrooksMBG,

Спасибо. Буду организовывать хранение картинки в БД.

Установите pragma page_size как минимум в 4 Кб, а то будете удивляться, почему медленно работает :-) К примеру, у постгреса по дефолту 8 Кб, а у эскулайт - 1 Кб. Притом увеличение с 1к до 4к дает 3-х кратный выигрыш производительности (увеличивать далее есть смысл, когда нужно хранить именно блобы). Можно и 32к попробовать, в рассылке эскулайта говорили, что для блобов на компакт-дисках самое то (под линуксом пробовал, разницы не видно, а под виндой не смотрел).

mrbrooksMBG
Установите pragma page_size как минимум в 4 Кб, а то будете удивляться, почему медленно работает :-)

Вот с этим сложнее ). Работаю через net.connector

Разве в нем нет возможности произвольные sql-запросы выполнять? Даже если так, то что мешает открыть базу через эскулайт шелл и настроить? Хинт: если база не пустая, то после установки этой прагмы нужно сделать vacuum.

mrbrooksMBG,
сделал:


теперь появляется мессага авторThe database disk image is malformed
и собственно все.
Хорошо что хоть бэкап сделал. Гы.

Вы бы рассказали, как этого добились :-) На ext3 за 5 лет активного использования в продакшен и тестирования мне такого не удалось сделать, хотя на на винмобайле у юзеров иногда бывает, когда КПК по питанию глючит. У вас случаем ФС не fat32?

mrbrooksв общем при обращении к базе в 180 мб гнется все что может. Учитывая положительные отзывы о SQLlite грешу только на сам ADO.NET. Это просто не реально хранить в БД картинки. Даже не обращаясь к самой таблице с изображениями тормоза неимоверные. Остановлюсь на варианте хранения на диске. Все достаточно быстро.

Так вы нашли самые большие из доступных грабель и прыгнули на них с высоты :-) Возьмите враппер с сайта эскулайт, там есть варианты для разных сред. Сам я работал с эскулайт напрямую, вкомпиливая в сишное приложение, и на tcl, проблем под виндой и винмобайл не было (и это притом, что софт исходно пишется под дебианом, ибо так удобнее).

mrbrooksMBG, дык я понял - но прихоть не моя. Сам клиент фактически готов и переписывать его под визуальную сишную библу желания нет. :)

Серж, спасибо за интересный тест. Меня тоже озадачили мои результаты. Ибо что админская прога, что работа из VS (причем под используемым коннектором) давали достаточно неплохие результаты. Значит трабла со стороны моего клиента однозначно. Путем вылизывания строки подключения добился сносных результатов. На машине 2,4 GH P4 512 ОЗУ время на возврат всех записей составило порядка 8 секунд + секунд 20 на прорисовку быдлогуя. Однако уже на машине 1,7 GH P4 512 ОЗУ - порядка 68 секунд + плюс столько же на быдлогуй =) Это уже хуже. Хотя по сравнению с тем, что творилось вчера - это прогресс.
Буду оттачивать подключение.

Для запросов делайте "explain query plan select ..." и смотрите, где индексов не хватает.