Genniy Сообщение 19/07/2010 06:36 Копия темы
Как лучше хранить фото в базе? Добрый день!   
Нуждаюсь в вашем совете.
Существует большая таблица в Oracle 10. Занесения данных в нее осуществляется через html-страничку с использыванием java-скриптов(как мне сказали).
Стала потребность в месте с данными этой таблицы хранить фотки. Сохранять фотки нужно через выше упомянутую html-страничку и просматривать также через браузер!

У меня вопрос следующий–   Как лучше всего организовать хранение дополнительной информации(фоток)?

Существуют такие ванианты:
1.   Можно добавить BLOB-поле в таблицу и хранить там. Вносить и читать данные с таблицы через php-скрипты.   
      Одна загвоздка, что нужно всем клиентам которые заносят инфу установить Client Oracle. И насколько это приемлемо хранить так данные... Таблица та большая и будет еще долго расти!!!
2.   Можно выделить FTP-сервер и фотки там хранить. А ссылки в новом поле таблицы. Сохранять и читать фотки думаю также через php(Хотя даже не смотрел возможно ли это реализовать :)).
      Доступ к серверу можно дать тем пользователям в которых есть доступ вообще к заполнению таблицы.

Вот такая загагулина.
У кого есть какие идеи–   рад буду ответу!
Спасибо.

abbat Сообщение 19/07/2010 06:44 Копия темы
Хранить фото в реляционной базе данных–   очень плохая идея.

artem82 Сообщение 19/07/2010 07:01 Копия темы
+ Храните фотки в ФС, а в базе–   адреса, ключи и параметры

Genniy Сообщение 19/07/2010 07:31 Копия темы
Чем можете объяснить, что плохая идея?

abbat Сообщение 19/07/2010 08:09 Копия темы
Опытом и здравым смыслом :)

Genniy Сообщение 19/07/2010 09:19 Копия темы
Да ответ хорош... :) Очень наполнен информацией.   Хотел разобраться.   
Ладно, спасибо за ответы!

dekameron Сообщение 19/07/2010 17:31 Копия темы
Тем, что при запросе на выборку к БД информация передается в среду РНР, в данном случае картинка будет зря обрабатыватся этой же средой.
Если не планируется никаких действий с самим изображением (фильтры, ватермарки и т.д.), то зачем создавать лишнюю нагрузку, если можно из БД тянуть только ссылку на картинку?
Думаю, не стоит сравнивать объем памяти, который занимает ссылка и картинка

artem82 Сообщение 21/07/2010 16:03 Копия темы
Анатолий, вы несколько неправильно понимаете технологию. Возможно, вам имеет смысл ближе познакомиться с технологией" клиент-сервер", а также понять проблематику, ради которой создавались, к примеру lighthttpd и nginx

r0k0t Сообщение 22/07/2010 11:26 Копия темы
Избегайте хранения BLOB в базе данных Начнём с практики:

1. Хранение изображений в базе данных (к пример MySQL)

Для записи изображения в базу данных из файла, используется функция ReadBLOB; считывания изображения из базы данных в файл используется функция WriteBLOB.
Функция ReadBlob возвращает количество байт, записанных в базе данных. Немного о работе функций: ReadBlob берёт файл, разбивает на блоки максимального размера (BlockSize = 32768 байт), затем данные блоками считываются из файла и вставляются в OLE поле базы данных. Функция WriteBLOB имеет схожий функционал, но сначала данные блоками размера BlockSize, считываются из базы текущей записи и сохраняются в файле (место в памяти).

2. BLOB (Binary Large Object) хранимый на SQL-сервере–   это текст огромный или изображение. Есть примеры, когда все изображения хранились в SQL-сервере. К примеру, молоток.ru домодернизации. Сейчас есть примеры, когда тоже лежат файлы на стороне базы данных MSSQL и Oracle. Обычно это базы данных автомобильные. Для MySQL нет эффективных способов хранения дизображений и их кеширования. В старших братьях такие способ появились.

3. Для того, чтобы понять где проблема с BLOB-ами посмотрим теорию. Итак, SQL-сервер не хранит BLOB на обычных страницах, где содержатся данные из других полей ряда таблицы. Сервер поддерживает лишь указатель на данные из объекта BLOB. Данные хранятся на 2кб страницах связанных через 16-битовый текстовый указатель. Получаем, что имеется, как минимум, приблизительно 2000 байт для хранения данных, если в поле не будет значения Null. Если поле принимает такое значение null, то размер этого хранилища равен 0, так как нет нужды использовать текстовые указатели. Таким образом, это означает, что на каждую запись с данными BLOB расходуется дополнительно еще по 2кб и это не предел.

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

К тому же, база данных в случае BLOB будет иметь плохо сжимаемаемый размер. Бэкапирования это–   будет Ваш полный кошмар! А вот, если файлы у вас отдельно, то все проще–   база маленькая, бэкапить без проблемы файлы отдельно и базу отдельно.

4. Вывод: Если объем данных существенный и к тому же у Вас MySQL или даже PostgreSQL, то лучше использовать отдельные файлы. Вдобавок файлы кешируются ещё и самой ОС, что очень удобно. А у СУБД будет только-то, что нужно кэшировать, и без всяких BLOB'ов.

Удачи.