Хранение изображений в DB - сетевые настольные приложения

Я бы посоветовал хранить эти файлы на диске в файловой системе, а не в базе данных. Файловая система для файлов, базы данных для реляционных данных и т. Д.

Доставка с помощью веб-службы

Рассмотрите возможность доставки этих изображений в ваше настольное приложение, разместив веб-службу / приложение на этой машине БД. Работа этого приложения - обслуживать только изображения. Настройте веб-сервер на этом компьютере с приложением ASP.NET. Используйте .ashx для обработки запросов и потоковой передачи двоичного изображения. Примерно так:

http: //myserver/myapp/GetImage.ashx? CustomerID = 123 & ImageID = 456

Безопасность

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

Безопасность файловой системы

Что касается безопасности этих образов, учтите, что NTFS дает вам множество мер, гарантирующих, что только те, кто авторизован, могут читать / удалять / помещать файлы по мере необходимости . Тогда задача состоит в том, чтобы определить эти роли и реализовать группы безопасности Windows.

Будущие потребности

Этот подход позволяет безопасно использовать эти образы из любого места в интрасети. Возможно, когда-нибудь это приложение будет перенесено в веб-приложение? Возможно, запрос функции исходит от клиента, если веб-решение подходит?

Это может показаться излишним, а не чтением большого двоичного объекта из базы данных, но это здорово с точки зрения безопасности. Учитывайте ожидания ваших клиентов и пациентов в отношении конфиденциальности и безопасности.

<%@ WebHandler Language="C#" Class="Handler" %>

public class Handler : IHttpHandler {

public void ProcessRequest (HttpContext context) 
{
    //go to the DB and get the path for this ID.
    string filePath = GetImagePath(context.Request.QueryString["ImageID"]);

    //now you have the path on disk; read the file
    byte[] imgBytes=GetBytesFromDisk(filePath);

    // send back as byte[]
    context.Response.BinaryWrite(imgBytes);
}

Сколько изображений мы говорим? Они уникальны / часто обновляются? Если нет, можете ли вы упаковать изображения с клиентом, который вы собираетесь распространять на несколько компьютеров?

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

Если вы прочитали через все другие похожие вопросы ( This , this и this ), но все еще спрашивают, хорошая ли это идея, тогда, возможно, ваша проблема в другом достаточно, чтобы это было хорошей идеей.

С точки зрения архитектуры вы получите максимальную производительность, разделив решение на две части: сервер базы данных и сервер изображений .

Вы должны сделать это как для сохранения небольших размеров строк, так и для отделения вашей транзакционной среды от содержимого. Реляционные базы данных в духе SQL Server и mysql будут поддерживать большие двоичные объекты, но не оптимизированы для них.

Большинство людей приравнивают «сервер изображений» к «веб-серверу», потому что они работают с веб-приложениями и, следовательно, имеют образ де-факто. репозиторий (каталог на локальном диске). Однако это не должно быть . Образы могут быть доставлены из любого места по любому протоколу.

Вы упомянули платформу C # /. NET и интрасеть. Можем ли мы предположить, что среда Windows, возможно, Active Directory?

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

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

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

Если вы выберете этот подход, я бы предложил несколько вид структуры каталогов в общей папке для упрощения резервного копирования, архивирования и т. д. Например:

\\ ImageServer \ MyAppRepository \ yyyy-mm \ {image-file-name-or-guid}. {ext} .

Надеюсь, что это поможет.

It seems to me that what you want to do something like what Infovark do.

They use Firebird for this and I'll give you a link on Firebird and storing image

If you're looking for alternatives, one of my favorites is a ten-line HTTP POST file upload handler (PHP, .NET, Java, etc.) + one webserver. When the script validates max file size, and possibly extracts the width & height, it inserts a row into the database. Retrieval need not go through the script. Standard file hosting will work. This would require you to open port 80. You needn't complicate this with SOAP or anything. A regular upload handler would do the job.

Then there's WebDAV, along the same lines. Of course, with this method, you'd have to monitor the filesystem and adjust the database accordingly. You could use a polling service or hook into file system events. Actually, you could also inject an ISAPI filter or Apache handler to perform the database updates.

You could use FTP. Add an extension to ProFTPd that will update the database and keep everything in sync.

Lots of ways to avoid putting image data into tables.

If you opt for the database solution, just be sure to segment your BLOBs into separate tables. Separate table spaces / devices / partitions, if you can. Or, use Oracle and ignore everything I've said.

I don't think it matters where the images are stored. Pick the simplest approach that will work. But you should have an architecture where you can change the approach if it proves to be the wrong one.

To accomplish this, I would put the data and the image storage both behind a web services interface. Pick a technology - doesn't matter. All access to the data (and images) would be the same way - through the web service.

By doing this, you have decoupled where the data is stored from the desktop application. The desktop app doesn't care. All it knows is that the server at a certain address can get it the data.

Then store the data and the images wherever you want. Choose the simplest thing for you. If you end up having issues, then (and only then) should you add additional complexity in order to solve the problem. The good news is that the additional complexity and work shouldn't affect the desktop applications at all. You can make the changes on the server without having to deploy a new version of the desktop applications.

вам следует попробовать MS SQl 2008, он поставляется с Type: FileStream, который автоматически сохраняет большие двоичные объекты в файловой системе.

Моя компания разработала приложение Windows Forms на C #, которое хранит изображения в базе данных, и это сработало очень хорошо. Активно пользуемся с 2003 года, в системе около 150 гигов данных.

Во-первых, позвольте мне сказать, что это НЕ оптимальная архитектура производительности. У нас были некоторые проблемы с обновлением статистики базы данных и правильной настройкой индексов. Мы в основном должны ежемесячно переиндексировать систему. Вы должны знать, что встроенная система оптимизации большинства серверов РСУБД не настроена для больших коллекций двоичных объектов.

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

Используйте хранилище Amazon S3 для своих изображений

Просто сохраните GUID или другое имя файла в базе данных

Amazon - это просто, быстро, дешево. безопасность и т. д. и т. д.

Он отлично масштабируется и, опционально, предоставляет CDN, подобные пограничным сервисам, непосредственно из S3

Хранение изображений в БД со временем, кажется, превращается в кошмар