Winforms Document Manager с использованием файловой системы и базы данных SQL

Question

Я пытаюсь создать менеджер документов для своего приложения winforms.Это не веб-интерфейс.

Я бы хотел, чтобы пользователи могли «прикреплять» документы к различным объектам (персоналу, компаниям, рабочим заданиям, задачам, партиям и т. Д.) В моем приложении.

После долгих исследований я принял решение использовать файловую систему для хранения файлов вместо BLOB-объектов в SQL.Я создам папку для хранения всех файлов, но я буду хранить информацию о документе (путь к файлу, загруженный, измененный, ревизия и т. Д.) В отношениях родитель-потомок с сущностью в базе данных sql.

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

Я также думал об использовании веб-службы, но некоторые наши клиенты просто запускают приложение наЕсть ноутбуки без Windows Server.Большинство из них используют Windows Server или Citrix / Windows Server.

Как лучше всего настроить это так, чтобы только приложение обрабатывало документы?

Answer 1

Я знаю, что вы сказали, что читали о больших двоичных объектах, но знаете ли вы о параметрах FILESTREAM в SQL Server 2008 и более поздних версиях? По сути, вместо сохранения больших двоичных объектов в базу данных, что не всегда является хорошей идеей, вы можете вместо этого сохранять большие двоичные объекты в файловой системе NTFS с использованием транзакционной NTFS. Для меня это звучит как то, что вы пытаетесь достичь.

Вся защита доступа к файлам будет осуществляться через SQL-сервер (так как это был бы единственный доступ к папке), и вам не нужно писать собственную логику для добавления и удаления файлов из файловой системы. Чтобы удалить файл из файловой системы, вы просто удаляете соответствующую запись в таблице сервера sql, и он обрабатывает удаление этого файла из файловой системы.

См:

http://technet.microsoft.com/en-us/library/bb933993.aspx

Answer 2

Вариант 1 (Легко): Безопасность через Obscurity

Предоставьте всем читателям (и пишите по мере необходимости) доступ к каталогам ваших документов. Сохраните «путь» документа в качестве полного URI (\\ имя_сервера \ dir1 \ dir2 \ dir3 \ file.ext), чтобы ваши пользователи могли получить доступ к файлам, но они не будут сразу доступны, если кто-то будет бродить по подключенным дискам.

Вариант 2 (сложнее): обслуживание файла с SQL Server

Вы можете использовать либо функцию CLR, либо SQLDMO, чтобы прочитать файл с диска, представить его как поле varbinary и восстановить его на стороне клиента. Плюс в том, что ваши пользователи увидят копию, а не реальную вещь; делает просмотр безопаснее, редактирование и сохранение сложнее.

Наслаждайтесь! ; -)

Answer 3

Я бы пошел с этими опциями, без определенного порядка.

1. Создать на сервере папку, недоступную пользователям. У вас должна быть запущена веб-служба на сервере (с использованием IIS или автономного приложения WCF), которая имеет метод для загрузки и загрузки файлов. Ваш веб-сервис должен управлять каталогом, в котором хранятся файлы. База данных SQL должна иметь все необходимые метаданные для поиска документов. Таким образом, только ваше приложение может получить доступ к этим файлам. Таким образом, пользователи могли видеть документы только через приложение.

2. Я вижу, что вы решили хранить документы в файловой системе. Я написал аналогичную систему (например, вложения для клиентов / заказов / продавцов / и т. Д.) За исключением того, что я храню ее в SQL Server. Это на самом деле работает довольно хорошо. Сначала я волновался, что такое большое количество данных замедлит работу базы данных, но это оказалось не так. Работает отлично. Единственный совет, который я могу дать, если вы выберете этот путь, - это создать отдельную базу данных для всех ваших вложений. Зачем? Потому что, если вы хотите получить копию СУБД для локального тестирования, вам не нужно копировать базу данных объемом 300 ГБ, которая состоит из 1 ГБ фактических данных и 299 ГБ вложений.

3. Вы упомянули, что некоторые из ваших пользователей будут носить с собой ноутбуки. В этом случае они могут быть не подключены к локальной сети. Если это так, я бы подумал о хранении файлов (и, возможно, самих метаданных) в облаке (EC2, Azure, Rackspace и т. Д.).