Відповіді:
Погляньте на цю відповідь:
Зберігання зображень у БД - так чи ні?
По суті, простір та показники продуктивності можуть бути досить великими, залежно від кількості користувачів. Крім того, майте на увазі, що веб-сервери дешеві, і ви можете легко додати більше, щоб збалансувати навантаження, тоді як база даних є найдорожчою та найскладнішою частиною веб-архітектури, як правило.
Є кілька протилежних прикладів (наприклад, Microsoft Sharepoint), але, як правило, зберігання файлів у базі даних не є гарною ідеєю.
Якщо, можливо, ви не пишете настільні програми та / або не знаєте приблизно, скільки користувачів у вас коли-небудь буде, але на такому випадковому та непередбачуваному, як загальнодоступний веб-сайт, ви можете заплатити високу ціну за зберігання файлів у базі даних.
Якщо ви можете перейти на SQL Server 2008, ви можете скористатися підтримкою FILESTREAM, яка надає вам найкраще з обох - файли зберігаються у файловій системі, але інтеграція бази даних набагато краща, ніж просто зберігання шляху до файлу в полі varchar. Ваш запит може повернути стандартний потік файлів .NET, що значно полегшує інтеграцію.
Я б сказав, це залежить від вашої ситуації. Наприклад, я працюю в органах місцевого самоврядування, і у нас є багато зображень, таких як знімки тощо. Ми не маємо великої кількості користувачів, але ми повинні мати хороший захист та аудит даних. База даних є кращим рішенням для нас, оскільки це робить це простіше, і ми не будемо стикатися з проблемами масштабування.
У чому тут питання?
Сучасні СУБД SQL2008 мають безліч способів роботи з BLOB-файлами, які не просто вписуються в них у таблиці. Звичайно, є плюси і мінуси, і, можливо, вам доведеться подумати про це трохи глибше.
Це цікава стаття пізнього (?) Джима Грея
BLOB чи ні BLOB: зберігання великих об’єктів у базі даних або файловій системі
З мого власного досвіду, завжди краще зберігати файли як файли. Причина полягає в тому, що файлова система оптимізована для зберігання файлів, тоді як база даних - ні. Звичайно, є деякі винятки (наприклад, багатовітна файлова система MS наступного покоління повинна бути побудована поверх SQL сервера), але загалом це моє правило.
Незважаючи на те, що продуктивність є проблемою, я думаю, що сучасні конструкції баз даних значно зменшили проблему для невеликих файлів.
Окрім продуктивності, це також залежить від того, наскільки тісно пов’язані дані. Якщо файл містить дані, які тісно пов'язані з полями бази даних, то він концептуально належить близько до нього і може зберігатися в BLOB-пам'яті. Якщо він містить інформацію, яка потенційно може стосуватися декількох записів або може мати певне використання поза контекстом бази даних, то вона належить поза. Наприклад, зображення на веб-сторінці отримується за окремим запитом від сторінки, що посилається на нього, тому воно може належати зовні (залежно від конкретного дизайну та міркувань безпеки).
Нашим компромісом, і я не обіцяю, що це найкраще, було зберігання невеликих файлів XML у базі даних, але зображень та інших файлів поза нею.
Ми прийняли рішення зберігати як varbinary для http://www.freshlogicstudios.com/Products/Folders/ на півдорозі, очікуючи проблем із продуктивністю. Я можу сказати, що ми були приємно здивовані тим, наскільки це вдало відпрацьовано.
Накладні витрати на синтаксичний аналіз blob (зображення) на байтовий масив, а потім записування його на диск із відповідним іменем файлу, а потім його читання достатньо накладних звернень, щоб відмовити вас робити це занадто часто, особливо якщо файли досить великий.