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

Здравствуйте Янцен Станислав Валентинович, Вы писали:



ЯСВ>Что лучше — хранить картинки в поле базы данных или в отдельных файлах, а в базе хранить только путь?
ЯСВ>База данных предназначена для хранения информации о сотрудниках. Доступ к базе через web браузер. Вроде для формирования HTML страницы проще брать картинку из файла. Или как сгененировать на лету страницу с картинкой из базы данных, не выводя ее в
файл?

если доступ полько через IIS, то наверное, лучше хранить в файлах
из БД на клиент можно отдать посредством ISAPI Extension
или на ASP: Response.BinaryWrite
см, напр, MSDN://PSDK/...BinaryWrite:
<%
Set objBinaryGen = Server.CreateObject("MyComponents.BinaryGenerator")
vntPicture = objBinaryGen.MakePicture
Response.BinaryWrite vntPicture
%>

Здравствуйте Янцен Станислав Валентинович, Вы писали:

ЯСВ>Что лучше — хранить картинки в поле базы данных или в отдельных файлах, а в базе хранить только путь?
ЯСВ>База данных предназначена для хранения информации о сотрудниках. Доступ к базе через web браузер. Вроде для формирования HTML страницы проще брать картинку из файла. Или как сгененировать на лету страницу с картинкой из базы данных, не выводя ее в файл?

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

Здравствуйте magcyril, Вы писали:

M>честно говоря, за хранение картинок в базе я бы руки отрывал
M>присваивайте имени файла цифровое имя и храните его в базе, а файлы на диске

А в чем причина такой нелюбви к хранению картинок именно БД?
Я сам не вижу особенной разницы. Хотелось бы услышать обоснование твоей позиции.

Здравствуйте VVP, Вы писали:

VVP>Здравствуйте magcyril, Вы писали:

M>>честно говоря, за хранение картинок в базе я бы руки отрывал
M>>присваивайте имени файла цифровое имя и храните его в базе, а файлы на диске

VVP>А в чем причина такой нелюбви к хранению картинок именно БД?
VVP>Я сам не вижу особенной разницы. Хотелось бы услышать обоснование твоей позиции.

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

достаточно?

Кирилл

Здравствуйте magcyril, Вы писали:

M>1. может сильно расти база, нагрузка на сервер и требования к аппаратным ресурсам
Сдается мне, что все это сильно зависит от возможностей сервера. Приведу следующий пример — на Оракле нет ограничений на размер строки таблицы, поэтому я могу хранить в БД блоб-поля более 64К размеров, Оракл совершенно не тормозит при множественных запросах нескольких картинок, при этом мне достаточно одного сервера — сервера БД и не требуется файл-сервера для хранения изображений, правда сервер у нас очень мощный и специфика картинок существует (фотографии сотрудников, изображения товаров). А вот в Интербейзе существуют ограничения на размер строки — всего 64К, посему там особенно ничего не похранишь
M>2. файлы на диске оптимально кешируются как на уровне операционной системы, там и на уровне веб-сервера
Опять же зависит от сервера БД, тот же Оракл существенно оптимизирует хранение и кеширование данных, помогая избежать files slack. Что касается веб-сервера, то ответить не могу, не занимался конфигурацией оных.
M>3. при хранении картинок в базе придется изрядно извратиться, чтобы показать их по http, каждый запрос картинки по ее url будет приводить к изрядным накладным расходам
Опять вопрос к серверу БД. Но! Какже быть с динамически формируемым HTML, ведь самое выгодное дело сложить данные для него в БД и серверный процесс будет заниматься формированием страниц и выкладыванием их в нужный каталог сервера?

M>достаточно?
Нет, пожалуй не достаточно. Ты привел аргументы из области веба. Мне же хотелось услышать описание проблем, возникающик в клиент-серверных приложениях интрасети.
Хотя твои аргументы и очень весомы, да и сам я придерживаюсь похожей политике — хранить изображения отдельно, а ссылки на них — в БД.

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

из того, что многие sql сервера позволяют хранить в таблицах большие объемы бинарных данных, не следует, что это нужно делать.

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

будучи размещенным на веб-сервере, файл будет кешироваться только в случае его частой используемости и количества свободной оперативной памяти. если файл загнать в базу, то sql сервер будет пытаться кешировать базу целиком, даже если файлы будут запрашиваться очень редко. согласитесь, что если база текстовая, то она меньше объемом и ее легче закешировать целиком?

наглядный пример: есть пара sql серверов и несколько вэб-серверов, сервера соединены между собой с помощью 100Mbit свича, вполне реальна ситуация (сталкивались), когда пропуской способности этого 100MBit свича не хватит на передачу обычных текстовых запросов, а представьте себе, что надо по этому же каналу и бинарную информацию гонять (при каждом http запросе файла)? а если еще добавить репликацию между sql серверами таких баз?
тогда придеться переходить на гигабитное оборудование за очень хорошие деньги

VVP>Опять вопрос к серверу БД. Но! Какже быть с динамически формируемым HTML, ведь самое выгодное дело сложить данные для него в БД и серверный процесс будет заниматься формированием страниц и выкладыванием их в нужный каталог сервера?

динамические страницы на то и динамические, что они не хранятся в каталогах, а формируются на лету скриптами, текстувую информацию для них лучше хранить в бд

VVP>Нет, пожалуй не достаточно. Ты привел аргументы из области веба. Мне же хотелось услышать описание проблем, возникающик в клиент-серверных приложениях интрасети.

интрасеть отличается от интернет ограниченным количеством клиентов (как правило небольшим) и предсказуемой нагрузкой (тоже относительно небольшой), поэтому вопросы оптимизации не столь остры. но если вы планируете открыть доступ к вашим ресурсам неограниченному числу внешних пользователей, то легко можете столкнуться с ситуацией, когда интранет решения вообще никуда не годятся. а проблема, на мой взгляд, только одна — дополнительная нагрузка на sql сервер



Кирилл

Здравствуйте, Янцен Станислав Валентинович, Вы писали:

ЯСВ>Что лучше — хранить картинки в поле базы данных или в отдельных файлах, а в базе хранить только путь?

Я для java-классов сделал такую систему — в описатилях действий (таблтца Actions) есть поле ActionFormClassName, там хранится имя класса.
А вот с фотками автомобилей не могу определиться окончательно. Даже содержание этой ветуи не стало последней каплей на весы в этом вопросе.
Думаю сдедать так:
Есть у автомобмлей строковой ключ — номер транспортного средства (VI-номер в паспорте автомобиля). И вот думаю называть фотографии (файлы) по этому ключу, не думаю что это будут монструозные кадавры, скорее всего Jpg меньше 32 кб. потому и гложат сомнения, а не положить мне это в INPUTSTREAM-поля таблицы Cars бд DataStore?
Что Вы об этом думаете (об обоих вариантах)? Както поубедительней пожалуйста.

Не забывайте еще и о том, что браузеры тоже кэшируют картинки, и весьма эффективно. Поэтому множественные заходы на страницу с картинками не будут вызывать повторных запросов на их загрузку. Кроме того веб-сервер тоже может кэшировать http ответы, независимо от того, текст там или картинка. Если все картинки статические, то наверное можно так настроить веб-сервер, что каждая картинка будет вытягиваться из базы только один раз, а потом сидеть в кэше (если конечно памяти достаточно).

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

Здравствуйте, wildwind, Вы писали:

W>Поэтому я тоже склоняюсь к тому, что принципиальных за или против хранения картинок в БД нет. Высокой производительности и масштабируемости можно добиться и так и эдак. А решение нужно принимать, исходя из требований к гибкости, целостности, сопровождаемости, удобству и т.п. И конечно, проведя ряд тестов на предполагаемой конфигурации.
Всё это не добавляет груза на весы в какую-либо конкретную чашу, но только ещё более запутывает ситуацию, затрудняя выбор. В моём случае речь о вебе не идёт — клиент сервер с "распиленой логикой" (смысл жизни клиентской логикой — гарантировать максимально возможную корректность пользовательского ввода, и предоставить инструмент изменения/просмотра некоторого набора сущностей). Последнее сказано потому стоь абстрактно, что система у меня устроена приблизительно так:

Сушности предметной области  ^
                             |
клиент ----------------------+----------->сервер
                             |
Сущности поддержки Системы   |

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

Здравствуйте, Волк-Призрак, Вы писали:

ВП>В моём случае речь о вебе не идёт — клиент сервер с "распиленой логикой"
Ну я отвечал скорее тем у кого веб.

ВП>Итак, вопрос о том, как хранить фотографии автомобилей, остаётся открытым.

Архитектуру твою я понял, но из нее мало что следует в плане хранения картинок. Начни с того, почему этот вопрос кажется тебе важным? Каких последствий неверного выбора ты опасаешься? Падения производительности, роста сетевого трафика, ...? (Кстати, в любом случае стоит сразу заложить возможность легкого перехода с одного метода на другой, а то и на их комбинацию.) То есть каковы критерии выбора?

Здравствуйте, Янцен Станислав Валентинович, Вы писали:

ЯСВ>Что лучше — хранить картинки в поле базы данных или в отдельных файлах, а в базе хранить только путь?

Если СУБД десктоповая (Access/Jet, MSDE) — то однозначно не стоит — хотя бы из-за предела размеров базы в 2Гб.

Здравствуйте, wildwind, Вы писали:

W>Архитектуру твою я понял, но из нее мало что следует в плане хранения картинок. Начни с того, почему этот вопрос кажется тебе важным? Каких последствий неверного выбора ты опасаешься? Падения производительности, роста сетевого трафика, ...? (Кстати, в любом случае стоит сразу заложить возможность легкого перехода с одного метода на другой, а то и на их комбинацию.) То есть каковы критерии выбора?
Падения производительности, и проблем при переносе бд с компа на комп, скажем при показе системы "заказчику" (в данном случае преподу но это не суть важно").
Да и траффик итак большой — зипованые объекты явы.

Здравствуйте, nzeemin, Вы писали:

N>Здравствуйте, Янцен Станислав Валентинович, Вы писали:

ЯСВ>>Что лучше — хранить картинки в поле базы данных или в отдельных файлах, а в базе хранить только путь?

N>Если СУБД десктоповая (Access/Jet, MSDE) — то однозначно не стоит — хотя бы из-за предела размеров базы в 2Гб.
JDataStore даёт 8 терабайт или чёто уколо того (правдая думаю журналы к такой большой базе будут окталионы байт весить каждый но это детали)

Здравствуйте, Янцен Станислав Валентинович, Вы писали:

ЯСВ>Что лучше — хранить картинки в поле базы данных или в отдельных файлах, а в базе хранить только путь?
ЯСВ>База данных предназначена для хранения информации о сотрудниках. Доступ к базе через web браузер. Вроде для формирования HTML страницы проще брать картинку из файла. Или как сгененировать на лету страницу с картинкой из базы данных, не выводя ее в файл?

Что лучше — желательно решать на основании каких-то критериев. Как-то использовали и тот, и другой вариант.

С точки зрения удобства поддержки ресурса — лучше в БД (нет проблем с резервным копированием, доступом через файловую структуру, безопасностью и целостностью данных).

Если указанные параметры не критичны (т.е. о них задумываться не нужно), то можно и в файлах. Некоторый выигрыш по производительности получите.

P.S. Генерация на лету делается просто (по крайней мере в ASP). Общий принцип — замена MIME-типа в заголовке Response и выдача потока байтов (картинки) в этот Response.