Как хранить изображения в базе данных

Как хранить фото для товара в БД?

Пишу интернет-магазин MVC Rest api с использованием Spring Boot , Hibernate , PostgreSQL . Мне необходимо иметь для товаров фотографии. Соответственно, отсюда вопрос как вообще это реализовать? Вариант с хранением картинок прямо в БД не подойдет, поэтому я решил хранить в БД ссылки на фото, которые у меня хранятся на жестком диске. Но как все это реализовать в коде? В Entity получается у меня поле с типом String ? Java:

private String image; 

alter table drink add column image varchar; 

А в БД столбец с ссылками (путь) к фото? В таком случае как вывести изображение на стороне клиента, ведь мне будет выдаваться не фото, а ссылка? Получается нужно писать некий метод, который будет до вывода находить файл по ссылке и выводить его? Но как?

Сохранение изображения в БД C#

Порой необходимо сохранить те или иные изображения в базу данных. Сохранять в бд путь до картинки не самый оптимальный выход из ситуации, так как это будет работать локально на одном пк и то не всегда.

Оптимальным выходом из данной ситуации является представление изображения в виде массива байтов byte[]

Набор байтов — это самый простой способ представления файла изображения в виде данных. Строка не подходит, поскольку она содержит коды символов, а файл изображения не состоит из символов. Так как не существует специального класса для хранения данных файла изображения, для этого отлично подходит массив байтов.

Любой файл можно рассматривать как набор байтов, поэтому массив байтов является результатом чтения файла в виде двоичных данных. Файл также может быть декодирован как определенный формат, например, текстовый файл, результатом которого является строка, или формат сжатого изображения (JPEG, GIF, PNG и т. д.), результатом которого является Bitmap.

Программное обеспечение

Microsoft SQL Server

Microsoft SQL Server является одной из наиболее популярных систем управления базами данных (СУБД) в мире. Данная СУБД подходит для самых различных проектов: от небольших приложений до больших высоконагруженных проектов.

SQL Server был создан компанией Microsoft. Первая версия вышла в 1987 году. А текущей версией является версия 2019, которая вышла в 2019 году и которая будет использоваться в текущем руководстве.

SQL Server долгое время был исключительно системой управления базами данных для Windows, однако начиная с версии 16 эта система доступна и на Linux.

SQL Server характеризуется такими особенностями как:

• Производительность. SQL Server работает очень быстро.
• Надежность и безопасность. SQL Server предоставляет шифрование данных.
• Простота. С данной СУБД относительно легко работать и вести администрирование.

Центральным аспектом в MS SQL Server, как и в любой СУБД, является база данных. База данных представляет хранилище данных, организованных определенным способом. Нередко физически база данных представляет файл на жестком диске, хотя такое соответствие необязательно. Для хранения и администрирования баз данных применяются системы управления базами данных (database management system) или СУБД (DBMS). И как раз MS SQL Server является одной из такой СУБД.

SQL Server Management Studio

Для удобного управления базами данных и различными опциями и настройками в MS SQL Server установим специальное средство администрирования, которое называется SQL Server Management Studio (SSMS). Данную программу можно использовать для создания баз данных и их таблиц, написания и выполнения запросов к бд, а также для много другого.

Реализация

Приступим к реализации поставленное задачи, а именно сохранение изображение в БД.

Шаг.1 Создадим простой проект WPF, назовем его Image Test WPF (Рис.2)

Шаг.2 Добавим на форму компонент Image, установим его атрибут name как «image», а также зададим его ширину и высоту(Рис.3)

Код

Шаг.3 Добавим кнопку для выбора изображения (Рис.4)

Код

Шаг.4 Пропишем код для открытия диалогового окна выбора файла

Для этого пропишем событие клика кнопки

Код

Два раза нажмем по кнопке и перейдем в метод (Рис.6):

Далее пропишем код для вызова диалогового окна выбора файла OpenFIleDialog

Пропишем подключение нужных директив

using Microsoft.Win32; using System.IO;

Код

private void SelectImage(object sender, RoutedEventArgs e) < OpenFileDialog openFileDialog = new OpenFileDialog(); // создаем диалоговое окно openFileDialog.ShowDialog(); // показываем byte[] image_bytes = File.ReadAllBytes(openFileDialog.FileName); // получаем байты выбранного файла >

Шаг.5 Создадим базу данных

В программе My Sql Management Studio создадим в базе данных таблицу и назовем ее Images (Рис.8)

Установим для поля image тип данных varbinary(MAX)

Шаг. 6 Допишем код выбора изображения с использованием библиотеки для сохранения изображения

Скачайте файл с github и поместите в ваш проект (Рис.9)

И в данном классе пропишите библиотеки:

using System.Drawing; using System.Drawing.Imaging; using System.IO; using System.Windows.Media.Imaging;

Добавим в проект класс для работы с базой данных

Переменную sqlConnection замените на свои данные

Шаг. 7 Добавим еще одну кнопку для загрузки изображения из базы данных (Рис.11)

Шаг. 8 Напишем логику загрузки изображения из БД, а также сохранения

Дополним код выбора изображения так, чтобы он еще и сохранял выбранное фото в БД (Рис.12)

private void SelectImage(object sender, RoutedEventArgs e) < OpenFileDialog openFileDialog = new OpenFileDialog(); // создаем диалоговое окно openFileDialog.ShowDialog(); // показываем byte[] image_bytes = File.ReadAllBytes(openFileDialog.FileName); // получаем байты выбранного файла string connectionString = "server=192.168.140.128;Trusted_Connection=No;DataBase=Test;User=s;PWD=s"; // строка подключения using (SqlConnection connection = new SqlConnection(connectionString)) // создаем подключение < connection.Open(); // откроем подключение SqlCommand command = new SqlCommand(); // создадим запрос command.Connection = connection; // дадим запросу подключение command.CommandText = @"INSERT INTO images VALUES (@ImageData)"; // пропишем запрос command.Parameters.Add("@ImageData", SqlDbType.Image, 1000000); command.Parameters["@ImageData"].Value = image_bytes;// скалярной переменной ImageData присвоем массив байтов command.ExecuteNonQuery(); // запустим >>

Пропишем логику загрузки из БД:

 private void LoadImage(object sender, RoutedEventArgs e) < DataTable matcher_query = SqlModel.Select("SELECT * from Images"); // запрос image.Source = ByteImage.Convert(ByteImage.GetImageFromByteArray((byte[])matcher_query.Rows[matcher_query.Rows.Count - 1][0])); // берем из запроса последнюю строку и ее массив байтов >

Шаг. 9 Протестируем программу

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

Далее выберем изображение и нажнем загрузить

Как видим все работает!

Объяснение кода загрузки

ByteImage.Convert() — преобразует изображение в понятный для wpf вид

ByteImage.GetImageFromByteArray() — преобразует массив байтов в иозображение

 image.Source = ByteImage.Convert(ByteImage.GetImageFromByteArray(массив байтов);

Преобразует массив байтов в изображение, конвертирует его в понятный для wpf вид и устанавливает в компонент image

Краткий экскурс по работе с библиотекой

Скачайте файл с github и поместите в ваш проект файл

Чтобы перевести массив байтов byte[] в изображение и поместить его в компонент Image нужно соделать следующее:

ByteImage.Convert(ByteImage.GetImageFromByteArray(массив байтов));

Чтобы перевести изображение в массив байтов нужно сделать следующее:

byte[] some_image_bytes = File.ReadAllBytes("image.jpg");

Вывод

Сохранение изображения в БД не такая уж сложная задача. Если использовать написанную мной библиотеку, то код сводится к минимуму , грубо говоря в одну строку.

• .NET
• Администрирование баз данных
• C#
• Разработка под Windows

Хранение изображений сайта в БД

Автор должен признаться: статья родилась и выросла из довольно небольшой и не претендующей на откровение оптимизации сайта, описанного в другом материале. Сайт этот связан с музыкальной тематикой и, соответственно, активно отображает обложки альбомов, хранящиеся (до поры до времени) на сервере не в ФС , как обычно бывает, а в БД SQL Server (в BLOB-поле, о чём несложно догадаться); в старом варианте пора извлечения изображений из базы и сохранения их в виде файлов возникает в момент запроса альбомов пользователем, после чего (по истечении сессии) они удаляются.

Чтобы почти окончательно развеять куцую интригу и помочь возможному читателю определиться с тем, имеет ли смысл продолжить чтение, опишу конечный результат оптимизации: обложки по-прежнему останутся в базе данных, причём в поле того же типа, но вот веб-сервер, отдающий в итоге изображения клиенту, будет «обманут» и станет обращаться за файлом знать не зная, что его на самом деле нет в ФС, а вызов идёт сразу и непосредственно к СУБД. Такой «обман» конечно же не является самоцелью – всё в основном затевалось ради уменьшения нагрузки на дисковую подсистему.

Старая реализация

Прежде всего необходимо напомнить структуру HTML-тэга img , обязательным у которого является лишь атрибут src :

У несложных сайтов изображение, находящееся по URL в этом атрибуте, веб-сервер обычно напрямую извлекает из ФС, т. к. относительный путь к нему очень часто совпадает со структурой каталогов на сервере, а имя файла тоже берётся непосредственно из ФС; однако такое распространённое поведение, если брать конкретно IIS (именно он применяется в данном проекте), может быть заменено на совершенно другое за счёт модулей (расширений), когда изображения станут, к примеру, генерироваться на лету (т. е. физически они нигде не хранятся). Так вот статья затрагивает лишь первый вариант.

На этом сайте обложки располагаются не в файловой системе из-за желания «всё своё носить с собой» – чтобы резервная копия БД содержала полный набор информации, была самодостаточной; соответственно, дабы веб-сервер мог отдать изображение клиенту, оно, как уже говорилось, должно быть извлечено из базы данных и сохранено в виде файла, что добавляет лишнюю операцию: сначала читаем из БД, после чего записываем копию на диск, бездарно и теряя дисковое пространство, и нагружая эту подсистему. Ко всему прочему, если несколько разных пользователей относительно одновременно запросят одну и ту же обложку, то из-за того, что в uniGUI каждый из них представлен отдельной сессией, файл дополнительно продублируется ещё и для каждой из них.

Схематически и упрощённо описанное непотребство можно представить следующим образом:

Если проиллюстрировать прошлую реализацию кодом, то его логика будет иметь довольно классический вид:

1. Запрос на выборку данных возвращает, среди прочих, и BLOB-поле с обложкой (в данном случае на примере компонента spAlbums типа TFDStoredProc из состава FireDAC).
2. Изображение из поля, в зависимости от формата (png, jpg…), загружается в соответствующего наследника TGraphic.
3. Далее используется предоставляемая uniGUI функция uniImageToURL , сохраняющая изображение в нужную папку и возвращающая готовый URL для атрибута src .

uses System.SysUtils, System.Classes, Data.DB, Vcl.Graphics, Vcl.Imaging.jpeg, Vcl.Imaging.pngimage, Vcl.Imaging.GIFImg, uniGUIUtils; function TMainForm.AlbumsToHTML: string; function CoverURL: string; var CoverFormat: string; Image: TGraphic; ImageStream: TStream; begin CoverFormat := spAlbums['CoverFormat']; if CoverFormat = 'jpg' then Image := TJPEGImage.Create; if CoverFormat = 'png' then Image := TPngImage.Create; if CoverFormat = 'gif' then Image := TGIFImage.Create; if CoverFormat = 'bmp' then Image := TBitmap.Create; try ImageStream := spAlbums.CreateBlobStream ( spAlbums.FieldByName('Cover'), bmRead ); try Image.LoadFromStream(ImageStream); finally ImageStream.Free; end; Result := uniImageToURL(Image); finally Image.Free; end; end; const AlbumHTMLTemplate = '
' + '
' + '' + . '
' + '
'; begin spAlbums.First; while not spAlbums.Eof do begin Result := Result + Format( AlbumHTMLTemplate, [CoverURL, . ] ); spAlbums.Next; end; end;

Идеальный вариант

Если предаться мечтаниям и представить, что обложки по-прежнему находятся в БД в BLOB-поле, а IIS каким-то образом, почти без усилий и программирования с нашей стороны, сам извлекает их, то окажется, что SQL Server способен такую мечту исполнить – за счёт функционала FileTable, представляющего собой, если очень кратко, создаваемую разработчиком специального вида таблицу, каждая запись которой отображается в файл в NTFS; обращение к таким файлам ничем не отличается от стандартного (однако некоторые возможности не поддерживаются), т. е. их можно просматривать, изменять и удалять хоть через Проводник.

Если снова графически показать такую схему, то мы избавимся от копирования обложки в папку сайта:

Данный вариант полностью совместим и с отложенной загрузкой изображений, настраиваемой скажем через атрибут loading , т. е. если пользователь не прокрутит страницу сайта до некоторых обложек, то они и не будут прочитаны из базы (написанное, разумеется, справедливо и для случая, когда в браузере вообще отключен показ изображений):

Чтобы воспользоваться этой манной небесной, ниспосланной SQL Server, потребуется, само-собой, выполнить некоторые действия как на стороне СУБД, так и на стороне IIS, чему собственно и посвящена оставшаяся практическая часть статьи. Но предварительно хотелось бы сделать небольшую ремарку и отметить, что конкуренты Microsoft тоже могут предложить тонкую работу с BLOB, но функционал уровня FileTable автору удалось найти лишь у Oracle – речь о Database File System (DBFS). Остальные же игроки предоставляют лишь условно традиционный (но неизбежно СУБД-специфичный) API, несколько примеров:

1. PostgreSQL
2. Interbase
3. MySQL

Настройка SQL Server

По умолчанию FileTable-возможности отключены в SQL Server. Официальная документация содержит весьма подробную и внятную инструкцию по параметрам, которые необходимо задействовать как на уровне всего экземпляра, так и в конкретной базе данных, отчего не представляется разумным пересказывать здесь подобные тонкости – вместо этого автор сосредоточится на небольшом SQL-скрипте, выполняющем перенос обложек из существующей таблицы с альбомами в новую FileTable-таблицу (если же в Вашем случае файлы изначально в БД не хранятся, в отличие от данного проекта, то с их адаптацией к FileTable поможет документация).

Таблицы

Далее в скрипте предполагается следующая структура двух только что упомянутых таблиц (источника – с данными об альбомах, и приёмника – новой таблицы с обложками):

Поле	Тип данных	Описание
ID	integer	Первичный ключ.
Cover	varbinary(max)	BLOB-поле с собственно изображением, которое нужно перенести в новую таблицу.
CoverFormat	nvarchar(10)	Тип изображения (jpg, png и т. д.).
Прочие поля (название альбома, год издания и т. п.).

Поле	Тип данных	Описание
path_locator	hierarchyid	Первичный ключ.
file_stream	varbinary(max)	Содержимое файла (в нашем случае это изображение).
name	nvarchar(255)	Название файла (с расширением), отображаемое в ФС.
Прочие поля.

Поле	Тип данных	Описание
CoverID	hierarchyid	Внешний ключ на приёмник.
Прочие поля.

Скрипт

Все действия с базой логически делятся на несколько этапов:

Банальнейшее по реализации добавление поля CoverID в источник:

ALTER TABLE dbo.Album ADD CoverID hierarchyid;

DECLARE @Covers TABLE ( AlbumID integer NOT NULL, path_locator hierarchyid NOT NULL ); MERGE dbo.AlbumCover AS cover USING ( SELECT ID, CoverID, Cover, CAST( NEWID() as nvarchar(max) ) + '.' + CoverFormat AS FileName FROM dbo.Album ) AS album ON album.CoverID = cover.path_locator WHEN NOT MATCHED THEN INSERT (file_stream, name) VALUES (album.Cover, album.FileName) OUTPUT album.ID, INSERTED.path_locator INTO @Covers; UPDATE dbo.Album SET CoverID = path_locator FROM @Covers WHERE > Использование MERGE вместо конструкции INSERT продиктовано невозможностью в последней обратиться в блоке OUTPUT к полям любых задействованных таблиц (допустимы только поля той, в которую и происходит вставка). Другими словами, было бы нечем заполнить поле AlbumID табличной переменной @Covers , т. к. обращение ниже выполняется к таблице-источнику, а вставка идёт в dbo.AlbumCover :

. OUTPUT album.ID, . 

ALTER TABLE dbo.Album DROP COLUMN Cover, CoverFormat;

SELECT FileTableRootPath('dbo.AlbumCover');

Оговорка про «почти» связана с тем, что читатель может столкнуться с отсутствием доступа при попытке обратиться к означенным файлам – в этом случае следует ознакомиться с той частью следующего раздела, где описывается нюанс с правами. Также для определённости примем, что наш путь выглядит как \\ServerName\MSSQLSERVER\DatabaseName\AlbumCover (далее в другом примере будет отсылка к нему, где для наглядности потребуется конкретное значение).

Настройка веб-сервера

Хотя в текущем разделе демонстрация идёт на примере IIS, но большинство вещей применимы и к любому другому веб-серверу, ибо являются скорее ОС- и СУБД-специфичными.

Права на чтение

Если снова вернуться к атрибуту src тэга img , то становится очевидной небольшая проблема: путь в атрибуте должен быть относительным, а нужные изображения доступны лишь по UNC-пути. Решение довольно просто́ и заключается в создании символической ссылки в папке сайта; если условиться, что физически сайт располагается в каталоге c:\IIS\SiteName, а ссылка будет называться Covers, то её добавление выполняется следующей командой в консоли:

mklink /d "c:\IIS\SiteName\Covers" "\\ServerName\MSSQLSERVER\DatabaseName\AlbumCover"

Теперь атрибут src станет возможно заполнять подобным образом:

Доработки Delphi-кода, дающие показанное значение для src , будут приведены в конце статьи, а пока же остался важный нюанс с правами (в нашем случае достаточно лишь на чтение), причём делящийся на две части:

Предоставление доступа (на уровне ФС) пользователю IUSR и группе IIS_IUSRS для созданной символической ссылки:

Логин создаётся на основе Windows-пользователя вида IIS APPPOOL\ .

CREATE LOGIN [IIS APPPOOL\YourPoolName] FROM WINDOWS;

CREATE USER FileTableReader FOR LOGIN [IIS APPPOOL\YourPoolName];

GRANT SELECT ON dbo.AlbumCover TO FileTableReader;

Проверка подлинности

Последнее, что требуется настроить, относится непосредственно к IIS, а именно к проверке подлинности на сайте – чтобы она выполнялась от имени пула приложений, чуть выше только что получившего права на чтение обложек (если в сценарии читателя проверка обязана проходить от иного пользователя, то данный раздел можно пропустить, но при этом необходимо добавить ещё одну пару «логин-пользователь» как описано в предыдущем разделе, связав имя входа со значением из параметров проверки подлинности).

Новая реализация

В заключение осталось привести новый, значительно облегчённый по сравнению с предыдущим вариантом, код, ибо из БД уже не нужно извлекать само изображение – достаточно лишь получить имя файла с ним (из поля dbo.AlbumCover.name , имеющего в примере псевдоним CoverFileName ) и в неизменном виде подставить в атрибут src :

uses System.SysUtils; function TMainForm.AlbumsToHTML: string; const AlbumHTMLTemplate = '
' + '
' + '' + . '
' + '
'; SymbolicLinkName = 'Covers'; begin spAlbums.First; while not spAlbums.Eof do begin Result := Result + Format( AlbumHTMLTemplate, [SymbolicLinkName, spAlbums['CoverFileName'], . ] ); spAlbums.Next; end; end;

• Веб-разработка
• Delphi
• Microsoft SQL Server
• IIS
• Разработка под Windows

Как правильно хранить изображения — в файлах или в базе данных MySQL?

На сайте планируется очень большое количество качественных изображений.
Около 2-х тысяч.
Я знаю, что изображения можно хранить в виде файлов на диске (привычный ранее способ) а также, при использовании CMS, в базе этой CMS, например MySQL.

Средний размер каждого файла порядка 3-х мегабайт.

Вопрос в том, какой способ выбрать.
Цели 2:
1. Ускорить работу сайта.
2. Хоть немного усложнить «работу» сайтопи$дам-вэбмастерам.

Если есть альтернатива, прошу. (Сайт планируется строить на Друпал 6.9)

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

Комментарии

olk 17 февраля 2009 в 0:08

Второй пункт не понял (как можно усложнить работу «сайтопи$дам-вэбмастерам», когда имидж в конечном счете будет на экране ?):) но с точки зрения производительности — однозначно в файловой системе (особено файлы такого размера)

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

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

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

Значит, файловая система.
Просто сейчас так много программ для копирования содержимого сайтов..
Придётся, видно, гадить копирайтом на каждой фотографии. Всё равно «выкачают».
А у нас не хватает ума как защитить файлы на сервере от тупого «выкачивания».
Спасибо, будем учиться. Это никогда не поздно

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

Ветер 17 февраля 2009 в 2:05

Если будешь хранить в базе данных, то тебя хостер застрелит через пару секунд.

Разумное решение гадить копирайтом только если доступ к картинке пришел из вне.
А так как обычно боты скачивают, то запретить этим ботам доступ на сайт.

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

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

Camor 17 февраля 2009 в 9:41

Можно конечно заморочиться и настроить elite xml website на вывод картинок друпала, но это достаточно сложно и не для всех сайтов потянет, хотя возможностей будет куча. Защиту от того, что бы не тоскали картинки можно сделать на уровне сервера или просто ставить watermark на картинки, что тоже полезно. Ещё есть способ, прописать в .htaccess защиту основанную на user-agent этих программ.

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

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

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

«_FeliX_» wrote:
Мое личное субъективное мнение.

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

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

«Camor» wrote:

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

В полне возможно
Всеже правильность определяется задачей. Простым является стандартный способ хранения файлов. А для некоторых задач более подходят базы данных.

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

От воровства контента не защититься никак.

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

Безусловно только в файловой системе.
От воровства контента защитится не так уж трудно.
Вот идеи:
1. В каталог с файлами ставится .htaccess запрещающий прямой доступ к файлам по HTTP
2. Картинки отдаются только через PHP-скрипты
3. В скрипты встроить защиту с лимитом скачиваний за минуту/час/день (кому как нравится) с конкретного IP.
4. Если не очень затратно по ресурсам, то можно этими же скриптами прилеплять к картинкам watermark с URL-сайта.

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

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

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

Всё зависит ещё от целей защиты!
Например у человека галерея в миллион картинок (ну пусть нескольких тысяч). Браузером такую галерею не вытянуть и за год! А вот роботом (если никакой защиты не стоит) это сделать можно быстро!
Опять же наличие watermark гарантирует, что не будет проблем с доказательством авторских прав на данное изображение, если например картинка выкладывается с правами «только смотреть», но с запретом на распространение, а недобросовестные пользователи на этот запрет плюют.

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

1)От робота не защититься никак.
2)делать частотомерку для ip и куда её класть? посещаемый ресурс вполне себе может леч полежать. При этом — роботу вобще говоря спешить некуда — будет тянуть одну картинку в 3-4 секунды — и всё. за несколько суток стянется всё что угодно

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

1. С чего вы взяли? Помоему я уже написал как можно защитится
2. Частотомерку можно класть в БД (например MySQL). Посещаемый ресурс никуда лечь и полежать не ляжет. Тут всего-то надо при вызове страницы, выполнить два запроса: SELECT и UPDATE. Тот же Drupal выполняет десятки запросов к БД при вызове практически любой страницы и ещё никуда не лёг. Да, роботу спешить некуда, но после скажем 100 скачиваний в течении часа, ему придётся отдохнуть сутки. Вот и посчитайте сколько у такого робота займёт скачивание хотя бы 10 000 картинок. Таким образом ваши «несколько суток» превращаются в 100 дней. А если поумничать и ввести дополнительную обработку (скажем если двое суток подряд по 100 картинок, то в бан на неделю), то вообще период скачивания может растянуться на годы

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

Спасибо всем давшим консультацию!
Файлы.. только файлы .. > база.. только база..
Значит, выбираем файлы.

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

Да простят меня коллеги, но файлы нужно хранить в БД, НО при этом копию в файловой системе.
Т.е. при обращении к файлу смотрится его наличие в файловой системе, если нет — создаем из БД копию в файловой системе, и при последующих обращениях уже в БД не лезем.
Но Drupal так не делает.

Зачем?
Файлы в внутри нод — это часть контента, хранение контента должно быть единообразно.

При переносе сайта достаточно просто перенести БД.

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

Ветер 2 апреля 2013 в 14:26

и получить охрененную нагрузку на базу.

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