Не по своята същност, но ако имате големи BLOB обекти, които запушват вашите таблици и кеш паметта, това със сигурност ще доведе до спад в производителността.
Да, това е често срещан подход. Обикновено бихте направили нещо като папки, наречени на всяка таблица, с която са свързани, съдържащи имена на файлове, базирани само на първичния ключ (в идеалния случай цяло число; със сигурност никога нищо, изпратено от потребителя).
Това по-добра идея ли е? Зависи. Има предимства за простота на внедряване да имате само едно хранилище за данни и да не се притеснявате да дадете на уеб потребителя достъп за запис до каквото и да било. Също така, ако може да има няколко изпълнявани копия на приложението (например балансиране на натоварването активно-активно), тогава трябва да синхронизирате съхранението, което е много по-лесно с база данни, отколкото с файлова система.
Ако използвате файловата система, а не блоб, тогава въпросът е дали накарате уеб сървъра да го обслужва, като посочите псевдоним към папката?
- + е супер бързо
- + кешира добре
- - допълнителна конфигурация на сървъра:виртуална директория; се нуждае от подходящо файлово разширение, за да върне желания
Content-Type - - допълнителна конфигурация на сървъра:трябва да добавите
Content-Disposition: attachment/X-Content-Type-Optionsзаглавки, за да спре IE подслушването за HTML като част от мерки срещу XSS
или обслужвате файла ръчно, като накарате скрипт от страна на сървъра да го изплюе, както би трябвало да обслужвате от MySQL blob?
- - потенциално е бавно
- - изисква доста ръчна обработка на If-Modified-Since и ETag, за да кеширате правилно
- + може да използва собствените методи за контрол на достъпа на приложението
- + лесно добавяне на правилни заглавки Content-Type и Content-Disposition от обслужващия скрипт
Това е компромис, за който няма нито един глобално приет отговор.
