При использовании asp.net MVC core + EF core + возможность шифрования файлов. Какими будут различия между Blob, FileStream и File System, для управления файлами

Question

Я работаю над основным веб-приложением asp.net mvc, веб-приложение представляет собой рабочий процесс управления документами. где внутри каждого из этапов рабочего процесса пользователи могут загружать документы следующим образом: -

1. пользователи могут загружать документы со следующим ограничением; размер файла не может превышать 5 МБ + все документы внутри рабочего процесса не могут превышать 50 МБ, если администратор не одобрит его. они могут загрузить столько документов, сколько захотят.
2. у нас будет много просмотров, которые покажут шаг и все его документы, прикрепленные к нему, и пользователи могут выбрать загрузку документов.
3. у нас может быть неограниченное количество рабочих процессов. чем больше пользователей зарегистрируется в нашем приложении, тем больше будет рабочего процесса.
4. некоторые файлы могут быть помечены как конфиденциальные, поэтому они должны быть зашифрованы при хранении их либо внутри базы данных, либо внутри файловой системы.
5. мы планируем использовать ядро ​​EF в качестве слоя доступа к данным для нашего веб-приложения + сервер SQL 2016 или 2017.

Теперь мой вопрос - как нам управлять нашими файлами, где я нашел эти 3 подхода.

1. Blob.
2. FileStream
3. Файловая система.

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

Второй подход. будет иметь лучшую производительность по сравнению с первым подходом (Blob), но FileStream не поддерживается с EF + и не позволяет шифрование. поэтому мы должны исключить и это.

третий подход. хранения файлов внутри папки с идентификатором рабочего процесса + хранить ссылку на файл / папку внутри БД. позволит нам зашифровать файлы + будет работать с EF. и иметь лучшую производительность по сравнению с Blob (не уверен, действительно ли это для FileStream). единственный недостаток в том, что мы не можем достичь атомарности между файлами и связанными с ними записями внутри базы данных. но с добавлением некоторого кода мы можем справиться с этим сами. например, удаление записи базы данных приведет к удалению всех ее документов внутри папки, и мы можем добавить некоторые фоновые задания, чтобы убедиться, что все документы имеют записи базы данных, в противном случае удалить документы ..

Итак, исходя из вышесказанного, я обнаружил, что третий подход лучше всего подходит для наших нужд? так может кто-нибудь советовать по этому вопросу, пожалуйста? мои предположения верны? и есть ли четвертый или гибридный подход, который может быть лучше для нас?

Answer 1

Хотя современные СУБД были оптимизированы для хранения данных с привилегиями целостности и атомарности, базы данных должны рассматриваться как наименее наиболее альтернативные (сообщения типа StackOverflow, такие как this и this должны подтвердить выше) и, следовательно, третий упомянутый вариант или его улучшение - голосование.

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

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