Уважаемые мастера!
Хочу услышать Ваше мнение. Есть БД (FireBird), сервер и база в сети. В базе есть, к примеру, таблица User'ы, в которой поле Foto.
Так вот юзвери могут (и часто так делают) приность фотки с цифровиков, которые по 2-3 метра весят. Это ж если юзверей будет 500, то база полтора Гига?!
Как правильнее сделать в такой ситуации, чтобы основную базу не раздувать?
У самого на уме несколько вариантов:
1. Создать отдельную базу для картинок или таблицу во внешнем файле.
2. Автоматически пережимать картинки при загрузке (гемор)
3. Создать трёхзвенку, и хранить файлы отдельно в файловой структуре сервера, а в базе хранить только их имена.

Жду умных мыслей! :)

4. Ввести формат фото: например, 240х180

можно использовать mssql 2008, там как читал, появился специальный блоб тип который не хранится в базе, а хранится в файлах в специальной папке, в базе только ссылка на файл. никаких других изменений по работе с ним от обычного блоба нет.
ну или можно самому организовать подобное на более ранних версиях/других типах баз.

> Ввести формат фото: например, 240х180


да тоже не выход: 240х180 мало, хотя бы 400х600, и это пол беды. Беда в том, что на будущее предполагается хранить не только фото, но и более "массивные" вещи напр. личные файлы, которые могут быть произвольными (напр. наработка юзера в вёрде с пикчурзами метров на 100 :)
Хотелось бы получить нечто типа TheBat'а - как он в базе хранит почтовые вложения. Но блин базу дуть не хочецца...
Сам склоняюсь к 3 варианту. Если кто имеет опыт разработки подобных вещей, поделитесь мыслями

> 3. Создать трёхзвенку
не обязательно, можно наверное обойтись внешними процедурами/функциями, если база позволяет.

Зависит от цели, что это за фото и зачем.
Может чем больше разрешение тем лучше...
Самый простой ограничить формат
> например, 240х180

и если размер больше, то не грузить.
Хранить в файловой можно и без трехзвенки.
Самый правильный - автоматом уменьшать формат.

> и если размер больше, то не грузить.

ото ж!


> Хранить в файловой можно и без трехзвенки.

плиз как?
напоминаю, субд - Firebird.
Кстати, внешние таблицы с BLOB-полями создавать не позволяет...


> Самый правильный - автоматом уменьшать формат.

Ок, согласен. А как быть с этим:

> Беда в том, что на будущее предполагается хранить не только
> фото, но и более "массивные" вещи напр. личные файлы, которые
> могут быть произвольными (напр. наработка юзера в вёрде
> с пикчурзами метров на 100 :)

> [0] TheEd   (29.05.09 16:10)
> то база полтора Гига?!

Ну и что? Сотрешь какой нибудь фильм и места освободится еще столько же. 8-)

> 2. Автоматически пережимать картинки при загрузке (гемор)

В чем гемор то? Полно пакетных конвертеров. Да и пользователи не каждый день фоты меняют.

> > то база полтора Гига?!Ну и что? Сотрешь какой нибудь фильм
> и места освободится еще столько же. 8-)


Проблема не в месте, и фильмы на серваке не храню :)
Просто не хочется раздувать базу, в которой фотки - не основные данные. Хотелось бы ещё знать, насколько устойчив FB при работе с подобными пухлыми базами. Пользователей кстати может быть и гораздо больше - их каждый год может по 2-3 сотни добавляться. Так вот, если БД разрастётся до к примеру 500 гигов, сервак не заколбасит от этого? ;)

> [8] TheEd   (29.05.09 16:49)

сжимать можно на лету. С помощью того же TJpegImage или StretchBlt, если скорость не особо критична

> [8] TheEd   (29.05.09 16:49)
> Так вот, если БД разрастётся до к примеру 500 гигов

Василий Иванович,а в мировом масштабе можешь? (с) Петька
8-)

> Как правильнее сделать в такой ситуации, чтобы основную
> базу не раздувать?

При загрузке фотографии в базу создавать маленькую по размерам Preview и пихать ее в базу, а саму фотографию оригинального размера хранить отдельно на винте. В базе хранить имена внешних файлов.

> Так вот, если БД разрастётся до к примеру 500 гигов, сервак
> не заколбасит от этого? ;)

Есть такая ERP-система http://avarda.ru/. Они на сайте в тест-драйве про базы размером в 25ТБ рассказывают. Причин им не верить - нет, т.к. такую базу они показывали на стенде на всероссийской выставке производителей ERP-систем.

> Так вот юзвери могут (и часто так делают) приность фотки
> с цифровиков, которые по 2-3 метра весят. Это ж если юзверей
> будет 500, то база полтора Гига?!


И че ?


> 2. Автоматически пережимать картинки при загрузке (гемор)


только так и надо


> Беда в том, что на будущее предполагается хранить не только
> фото, но и более "массивные" вещи напр. личные файлы, которые
> могут быть произвольными (напр. наработка юзера в вёрде
> с пикчурзами метров на 100 :)


И че ?

У тебя в чем проблема-то ?


> Хотелось бы получить нечто типа TheBat'а - как он в базе
> хранит почтовые вложения


До сих пор Bat хранил вложения в папке в виде файлов - новые версии хранят в базе ? В какой ?

Если тебе кто посоветует хранить данные базы в виде файлов отдельно от базы - назови этого человека глупцом и не слушай его советов.

400*600 всего лишь 720 kb даже для BMP, не говоря уже об JPG и на 500 пользователей всего лишь 360 мб, для 500 гб нужно 700 000 польвателей и без разницы в базе или из вне это хранится, во втором случае усложняется обработка и снижается целостность данных.

Это для BMP, для JPEG на порядок или более пользователей потребуется более.

Всем спасибо, выводы сделал:
1. При загрузке пикчур пережимать и резать разрешение.
2. Не обращать внимания на размер базы.

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