Я планирую разработку приложения для фотогалереи для клиента. Я разрабатываю приложение в asp.net 3.5 и хочу его развить, чтобы я мог повторно использовать приложение на нескольких платформах, используя различные интерфейсы. В принципе, мне интересно, каковы недостатки и преимущества хранения изображений в базе данных в виде двоичных файлов, а не просто для хранения файлов в папке приложения.
Любые советы будут очень признательны!
Спасибо, Тристан
Недостатком хранения в виде двоичного файла является то, что вы удаляете размер базы данных до невероятных размеров. Если вы хотите использовать экспресс-версию SQL Server, которая ограничена 4 ГБ на базу данных, фотогалерея "скоро закончится".
Преимущество состоит в том, что вы можете легко манипулировать ограничениями доступа к каждому файлу и каждому пользователю. Вы просто смотрите на права пользователя и решаете, обслуживаете ли вы изображение или нет.
SQL Server 2008 поддерживает FILESTREAM хранилище.
Файлы хранятся на томе NTFS, как обычные файлы, но подлежат контролю транзакций и могут быть доступны через специальные имена файлов, переданные в функции Win32 API (и, конечно, любой API, построенный на нем) с дополнительные SQL Server проверки безопасности (например, параметры GRANT и т.д.).
Хранилище файловой системы обеспечивает гораздо лучшую производительность при сохранении и обслуживании изображений и поддерживается на всех платформах. Если вы можете жить без средств безопасности и транзакционных товаров, которые вы получаете из хранилища db, я бы пошел с файловой системой.
У нас было большое приложение LOB, в котором были указаны идентификационные данные банковских счетчиков о члене, стоящем перед ними. Наши текстовые данные были сохранены в SQL Server. Данные изображения сохранялись в файлах. В поле базы данных просто было имя файла. Этот подход хорошо работает, если вы находитесь за брандмауэром. Чтение и запись файлов очень просто. Проблема заключается в управлении файлами. Вы должны защитить файловую систему, чтобы случайные люди не могли просматривать каталог. Кроме того, резервные копии более сложны с потерянными файлами изображений. Вы должны сделать резервную копию базы данных и файлов изображений. Поля могут ссылаться на пути, которые больше не существуют. Например, некоторый ИТ-специалист решает переместить папку с изображением, и теперь все ссылки в db сломаны. Если ваше приложение должно передавать информацию через брандмауэр, я бы предложил сохранить изображения на SQL Server с использованием упомянутого хранилища FileStream.
Сохранение изображений в базе данных спасло бы нас от печали. Нам пришлось бы только делать резервную копию базы данных, она была бы более безопасной, ссылки никогда бы не сломались, и нам не пришлось бы перепрыгивать через обручи, чтобы получать файлы из сети вне брандмауэра.
Эта дискуссия ведется почти в любом сообществе SQL Server целую вечность. есть хорошие аргументы для обеих сторон, и определенно не один размер подходит для всех ответов. Это действительно зависит от вашей индивидуальной ситуации и от многих факторов, таких как количество пользователей, сред. размер файла, частота обновления, соотношение чтения/записи, дисковая подсистема yadayadayada...
Но, как вы говорите, SQLExpress, вероятно, самым важным фактором является ограничение максимального размера базы данных, и это очень хорошая причина для подхода к файловой системе. В любом случае, этот исследовательский документ может по-прежнему быть интересным для вас: В BLOB или не в BLOB: Большое хранилище объектов в базе данных или файловой системе?
Этот документ использовался на сайте Microsoft Research здесь: http://research.microsoft.com/apps/pubs/default.aspx?id=64525, но эта ссылка не работает для меня. С тех пор SQL Server прошел долгий путь. Quassnoi уже упоминал FILSTREAM, например.