Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2010.08.27;
Скачать: CL | DM;

Вниз

Как правильнее не раздувая базу, хранить в ней множество картинок   Найти похожие ветки 

 
TheEd   (2009-05-29 16:10) [0]

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

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


 
Ega23 ©   (2009-05-29 16:14) [1]

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


 
sniknik ©   (2009-05-29 16:22) [2]

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


 
TheEd   (2009-05-29 16:22) [3]


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


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


 
sniknik ©   (2009-05-29 16:25) [4]

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


 
Нат ©   (2009-05-29 16:26) [5]

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

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


 
TheEd   (2009-05-29 16:39) [6]


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

ото ж!


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

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


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

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

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


 
Sergey13 ©   (2009-05-29 16:41) [7]

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

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

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

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


 
TheEd   (2009-05-29 16:49) [8]


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


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


 
clickmaker ©   (2009-05-29 16:53) [9]

> [8] TheEd   (29.05.09 16:49)

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


 
Sergey13 ©   (2009-05-29 16:57) [10]

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

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


 
PEAKTOP ©   (2009-05-30 12:06) [11]

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


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


 
PEAKTOP ©   (2009-05-30 12:10) [12]

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


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


 
Игорь Шевченко ©   (2009-05-30 20:31) [13]


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


И че ?


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


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


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


И че ?

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


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


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

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


 
Anatoly Podgoretsky ©   (2009-05-31 12:49) [14]

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


 
Anatoly Podgoretsky ©   (2009-05-31 12:52) [15]

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


 
TheEd   (2009-06-01 08:26) [16]

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


 
Anatoly Podgoretsky ©   (2009-06-01 21:05) [17]

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



Страницы: 1 вся ветка

Текущий архив: 2010.08.27;
Скачать: CL | DM;

Наверх




Память: 0.51 MB
Время: 0.084 c
2-1272273312
HF-Trade
2010-04-26 13:15
2010.08.27
положение TStatusBar после SW_Restore


15-1269984282
Petr V. Abramov
2010-03-31 01:24
2010.08.27
а давайте обсудим весну :)


15-1268600885
Кто б сомневался
2010-03-15 00:08
2010.08.27
Газик


15-1267459908
PEAKTOP
2010-03-01 19:11
2010.08.27
Первая Украинская конференция по Firebird


4-1236197897
d@vinchi
2009-03-04 23:18
2010.08.27
Как получить зарегистрированные в системе TAPI-линии