Большие картинки в БД

← →
DmitrichJ (2007-04-18 16:45) [0]

Как вы решаете проблему хранения больших картинок в БД? Есть ли резон хранить их в БД или просто складывать в папку, а в БД хранить путь. Особенно, когда БД в сети и около 40 пользователей. Спасибо.

← →
Sergey13 © (2007-04-18 16:49) [1]

Если тебе нужен поный контроль за картинками, то лучше в БД хранить. Если картинки - это просто картинки - все равно.

← →
DimaBr © (2007-04-18 16:52) [2]

Большие это сколько ??? Какая сетка, какой винт, сколько пользователей их видят, как часто делается бэкап и на какой носитель, как часто добавляются картинки, каков (приблизительно) суммарный объем картинок в базе ?

← →
Desdechado © (2007-04-18 16:57) [3]

1. Хранение пути требует расшаривания сетевого ресурса или создания локальных копий картинок. А это не всегда приемлемо.
2. Хранение пути накладывает ограничение на именование сетевого ресурса или локальных путей.
3. Хранение пути не обеспечивает целостности БД, если вдруг чего случится.
4. Хранение пути - усложнение администрирования прав доступа к данным, т.к. часть контроля прав возлагается на файловую систему.

← →
Desdechado © (2007-04-18 16:58) [4]

Все перечисленное неактуально, если БД локальная однопользовательская с относительными путями хранения файлов.

← →
clickmaker © (2007-04-18 17:05) [5]

все перечисленное также неактуально, если раздачей картинок занимается специально обученный сервис (сервер). Т.е. end-user доступа непосредственно к файловой системе не имеет

← →
Stanislav © (2007-04-18 17:14) [6]

40 пользователей критично -не для всех СУБД

← →
Stanislav © (2007-04-18 17:20) [7]

Если СУБД поддерживает бэкап это еще 1 + в пользу БД.
Картинка хранящаяся в БД будет автоматически сохранена с резервной копией базы.

← →
DmitrichJ (2007-04-19 00:14) [8]

Прихожу к выводу, что лучше в БД. Они вставляются в отчёт. Большие это 5, а то и больше Мб. Кол-во 7 на одну запись. Записей уже около 100. Будет гораздо больше.
Сейчас использую InterBase 6 (фотки в БД). но работает он на Server 2003 очень медленно. и много связаных с IB6 проблем. Денег естествено на IB7 (где проблем нет) естественно нет (если, конечно нельзя его где-то скачать). Хочу перевести в MS SQL 2000, но не могу добавить туда картинку. Уже поднимал этот вопрос, но так и не получил конкретного ответа.

← →
Jeer © (2007-04-19 01:33) [9]

> DmitrichJ (19.04.07 00:14) [8]
>
> Прихожу к выводу, что лучше в БД.

Давно пришел к выводу, что лучше не в БД.
Много причин, в том числе - независимая от БД трансформация файлов-картинок. Впрочем, как всегда, все определяется предметной областью.

← →
Sergey13 © (2007-04-19 09:39) [10]

> [8] DmitrichJ (19.04.07 00:14)
> Сейчас использую InterBase 6

Выкинуть в первую очередь и поставить FireBird 1.5.4 (если юзаешь IBX) или 2 (если FIB+).

> очень медленно

Скорость работы на 90% зависит от качества программы, а не от серверных способностей. Вот например

> Большие это 5, а то и больше Мб. Кол-во 7 на одну запись.

Это значит, что прочитав даже всего одну запись ты читаешь минимум 35 мегов.

← →
SlymRO © (2007-04-19 10:05) [11]

Упаковать картинки?

← →
Ega23 © (2007-04-19 10:10) [12]

> Прихожу к выводу, что лучше в БД. Они вставляются в отчёт.
> Большие это 5, а то и больше Мб. Кол-во 7 на одну запись.
> Записей уже около 100. Будет гораздо больше.

create table Images ( ImgID int not null, ImgData image null, constraint PK_IMAGES primary key (ImgID) ) go /*==============================================================*/ /* Table: WorkTable */ /*==============================================================*/ create table WorkTable ( WTID int not null, WTName varchar(255) not null, ImgID1 int null, ImgID2 int null, ImgID3 int null, ImgID4 int null, ImgID5 int null, ImgID6 int null, constraint PK_WORKTABLE primary key (WTID) ) go alter table WorkTable add constraint FK_WORKTABL_REF1_IMAGES foreign key (ImgID1) references Images (ImgID) go alter table WorkTable add constraint FK_WORKTABL_REF2_IMAGES foreign key (ImgID2) references Images (ImgID) go alter table WorkTable add constraint FK_WORKTABL_REF3_IMAGES foreign key (ImgID3) references Images (ImgID) go alter table WorkTable add constraint FK_WORKTABL_REF4_IMAGES foreign key (ImgID4) references Images (ImgID) go alter table WorkTable add constraint FK_WORKTABL_REF5_IMAGES foreign key (ImgID5) references Images (ImgID) go alter table WorkTable add constraint FK_WORKTABL_REF6_IMAGES foreign key (ImgID6) references Images (ImgID) go

Суть улавливаешь?

> Это значит, что прочитав даже всего одну запись ты читаешь минимум 35 мегов.
Не совсем так. BLOB загружается на клиента по явному требованию. И, думаю, даже сервер читает его по требованию, а без требования он читает только указатель (локатор) на место хранения в БД.

Ega23 © (19.04.07 10:10) [12]
Сказал бы проще, что сделать кросс-таблицу, в которой к одной записи главной таблицы можно прилепить произвольное число картинок. И тогда загружать можно не все, а какие-то конкретные.

> Не совсем так. BLOB загружается на клиента по явному требованию.

Серьёзно? Чё-то у меня сомнения большие...

> [13] Desdechado © (19.04.07 10:54)

Это да, но если разместить на форме имиджи для всех картинок и нажать кнопочку показать, таки ИМХО, все и прочитается. Я к тому писАл, что продумывать эти вещи надо заранее, и например держать маленькие копии картинок для навигации по ним.

> А что делает, по-твоему, CreateBlobStream и чтение из него?

Ты хочешь сказать, что
create table Images ( ImgID int not null, ImgData image null, constraint PK_IMAGES primary key (ImgID) ) Select * from Images
после выполнения такого запроса при попытке прочитать данные из БЛОБа на клиенте будет каждый раз запрос к БД идти? (Я сейчас про ADO говорю)
Я всю жизнь считал, что ADO фетчит все записи до конца и независимо от типа полей в запросе.
Если я не прав, то просветите. Крайне интересно.

Про ADO говорить не буду, не знаю.

> на клиенте будет каждый раз запрос к БД идти
Это забота клиентского драйвера, а не клиентского приложения.

Большие картинки в БД Найти похожие ветки