файл базы данных, хранящий проблему безопасности
Хранить файлы в базе данных означает добавлять пользовательский код для обработки доступа к файлам. В то время как это предложение возможность реализовать сложные модели обеспечения безопасности, которые непосредственно не поддерживаются базовой операционной системой, чем больше кода Вы добавляете, тем больше возможность введения ошибок, которые поставят под угрозу безопасность / целостность данных.
В то время как я должен признать, что я не великий эксперт по SQL Server (но я действительно знаю немного о mysql), этот подход требует, чтобы код выполнился с полномочием суперпользователя в домене данных; в отличие от нормального доступа к файлу нет никакого разделения полномочия. Таким образом, если система поставлена под угрозу, она полностью поставлена под угрозу. В отличие от ситуации, где учетная запись пользователя ОС поставлена под угрозу - в широком масштабе уменьшается воздействие. Сравните это с проблемами из-за вирусов на платформах Microsoft по сравнению с платформами Unix - не трудно записать вирусы для Unix - но до самого последнего времени большинство систем Microsoft не потребовало разделения полномочия.
серверы являются в компании доступным только истинным безопасным соединением
Едва ли большое преимущество - смотрит на статистику для компромиссов данных - большинство является внутренним так или иначе.
это будет боль в заднице для восстановления всего, так как sql дампы взвесит тонну
Правда, хотя намного легче сделать разделенный / возрастающие резервные копии на базе данных, чем в файловой системе - но снова это означает добавлять больше кода = добавляющий больше ошибок. Большая проблема - то, что это - нестандартный способ работать. В то время как Вас можно уверить, что младший сотрудник мог появиться в Вашем узле аварийного восстановления с резервным копированием файловой системы и смочь восстановить данные легко, делание того же с резервным копированием приложения является другой историей. И конечно Вы намного более ограничиваетесь в выборе инструментов, которые Вы используете для автоматизированного доступа к Вашим файлам (резервное копирование, сканирование AV, дедупликация, архивируя....).
Кроме того, поставляя файлы через HTTP, Вы потеряли все управление совместным выполнением по файлам.
Другое соображение состоит в том, что, конечно, с mysql, когда-то таблица перерастает пространство на отдельном диске, добавляя больше способности, не тривиально.
Некоторые из этих последствий могли быть смягчены путем сохранения файлов в файловой системе, но путем обеспечения веб-фронтэнда. Если Вы делаете его правильно, то можно все еще использовать разделение полномочия (путем выполнения веб-сервера как прокси между браузером и обработкой в расчете на пользователя / обработкой сессии фактический ввод-вывод, работающий с полномочием аутентифицируемого пользователя). Но Вы все еще потеряли управление совместным выполнением и существуют другие типы уязвимости, которая могла быть использована.
Как ИТ-компания это - отличный способ вытащить деньги из Вашего клиента - продажа их что-то, в чем они не нуждаются, заставляя их сохранить их ключевые активы с помощью него, затем тарифицируя их за поддержку его. Но это - очень плохая идея с точки зрения Вашего клиента.