Хранение файлов 1С: Бухгалтерии предприятия во внешней СУБД. Расширение





Данное расширение предназначено для 1С БП 3.0.65.69. Его задача — разместить присоединенные файлы не внутри базы 1С, а во внешнем источнике.

Требования к системе

  1. Версия платформы 8.3.13. [1]
  2. Версия Бухгалтерии Предприятия 3.0.65.69.
  3. MS SQL Server 2008 R2 и старше.
  4. Клиент-серверный режим работы базы.[2]

Общий принцип работы

Данное расширение позволяет хранить файлы и изображения не в виде хранилища значения в реквизитах базы 1С, а во внешней SQL базе, что, в случае большого объема данных в файла, существенно экономит место на быстрых дисках и уменьшает время обслуживания баз (бекап, восстановление).

Расширение добавляет в конфигурацию справочник с настройками подключения к внешней базе SQL и регистр с указанием ссылки на эту настройку и идентификатором файла в этой базе. При прикреплении файлов в базу конфигурация ведет себя типовым образом, помещая файл внутрь базы 1С, однако внешняя обработка в составе расширения, при регламентном запуске будет переносить файлы по 1000 штук во внешнее хранилище. Считывание файла из базы переопределено расширением, в случае, если файл перемещен во внешнее хранилище, то он будет запрошен из него, если же хранится внутри базы 1С – то будет запрошен из нее.

Соответствие лицензионной политике 1С

Прямая цитата с сайта 1С:

«… обращаться к данным информационной базы только при помощи объектов "1С:Предприятия", специально предназначенных для работы с данными (запросы, справочники, документы и т.д.). Нельзя обращаться к данным информационной базы напрямую, минуя уровень объектов работы с данными "1С:Предприятия" — например при помощи средств СУБД или при помощи внешних компонент, которые реализуют прямой доступ к СУБД. Это ограничение распространяется на любые действия с данными, в том числе на изменение их структуры, а так же на чтение или изменение самих данных информационной базы или служебных данных "1С:Предприятия".»

Данное расширение работает с данными внутри базы 1С штатными средствами и обращается за хранимыми файлами во внешнюю базу, не нарушая таким образом лицензионное соглашение.

Дальнейшие планы

В расширении планируется реализовать следующий функционал:

  1. Механизм работы с несколькими хранилищами. На текущий момент система получает одно хранилище, которое пользователь установил основным, и сохраняет данные в нем. Пользователь может изменить это хранилище и новые файлы будут сохраняться уже в новое хранилище, а старый по прежнему будут храниться и открываться из старого. Планируется реализовать механизм, который позволит на основании некоторых входных данных определять, какое именно хранилище будет использовано при перемещении файла.
  2. Очистка хранилища. При пометке файла на удаление и удалении его из базы 1С, в случае использования расширения, из базы 1С удалится справочник прикрепленного файла и настройки связи справочника и внешнего хранилища. Однако, само содержимое файла так и останется во внешней базе. Для того, чтобы подобные файлы удалялись автоматически, нужно будет реализовать очистку внешних хранилищ от удаленных в базе 1С файлов.
  3. Реализовать хранение файлов на SQL сервере с использованием механизма FILESTREAM, когда файлы хранятся на диске сервера СУБД, а не в таблице базы. При этом, все операции над данными все равно происходят с учетом этих файлов на диске.

[1] Платформа должна поддерживать добавление расширением новых справочников и регистров сведений.

[2] Расширение можно использовать и для файловой базы, однако представляется маловероятным хранение в файловой базе такого объема присоединенных файлов, что для работы с ними было бы выгодно использовать внешнее хранилище. Так же в случае с файловой базой, вам придется решать вопрос с регламентным запуском самостоятельно, следуя инструкции к БСП.

7 Comments

  1. kwazi

    не очень понятно кто целевая аудитория данного решения. В чем преимущество скажем над хранением файлов в томах на диске?

    Защищенность?

    Reply
  2. Silenser

    (1)Надежность, защищенность, удобство бекапа, прежде всего для больших объемов данных.

    Reply
  3. Silenser

    (2) Забыл еще один плюс: в случае, если нужно хранить скан или файл в нескольких системах, то можно настроить их так, чтобы содержимое файла хранилось единожды и было доступно по его ИД, хранимому в базе SQL, что для больших объемов будет существенно экономить место.

    Reply
  4. aspirator23

    (3) Для целей этой разработки, наверное лучше сразу использовать Filestream или даже NoSql. Быстродействие в текущей реализации скорее всего сносно, но не очень? Особенно если прочитать Дальнейшие планы. 🙂

    Reply
  5. Silenser

    (4)

    Filestream

    Тут не все так однозначно. Я не нашел интерфейса для считывания файлов в FileStream в режиме потока, минуя ядро MS SQL и процессор, без использования внешних компонент. Получать же файлы через результат запроса и просто хранить файлы вне СУБД можно, но смысл тогда каков? При больших объемах файловая система может начать подтормаживать. Для такого режима хранения рекомендуется проводить дефрагментацию. MS сама честно все об этом говорит. Я подумаю, как решить эту проблему, но использовать FileStream и получать файл через результат запроса не оптимально, ИМХО.

    (4)

    NoSql

    Текущая версия позволяет использовать MongoDB через RESTHeart. Но опять же, какова конечная цель? Как раз недавно Инфостарт проводил опрос по используемым СУБД. Не так уж много людей используют что-то, кроме MS SQL в компаниях, где установлена 1С. Для того, чтобы держать файлы на NoSQL, требуется как минимум админ, который понимает, как настраивать и устанавливать эту СУБД, а так же пользователи, которые будут использовать именно ее. Я готов разработать механизм хранения в NoSQL, если меня заинтересуют ;), иначе это просто работа в корзину. Вторая по популярность СУБД — Postgress, тоже поддерживается моим расширением.

    (4)

    Быстродействие в текущей реализации скорее всего сносно, но не очень?

    Быстродействие чего? Мое расширение работает довольно быстро, на уровне типового механизма хранения файлов в ХранилищеЗначения. Если речь про хранение файлов в режиме FileStream, то особой скорости обычно и не требуется. Важнее надежность.

    Reply
  6. aspirator23

    (5) Под быстродействием я понимал скорость записи файлов во внешнюю базу данных.

    Кажется запись больших файлов в MSSQL, используя FileStream быстрее чем обычной записи.

    Вот в тему публикация на инфостарте: https://infostart.ru/public/538764/

    Другие рассуждения об этом:

    http://download.microsoft.com/download/0/9/4/0947BFC2-9942-4365-ACAE-CEC9C7958E66/FILESTREAMStorage.docx

    http://www.sql.ru/forum/1245719-2/kak-uluchshit-skorost-zapisi-chteniya-blobov

    https://blogs.msdn.microsoft.com/alexejs/2009/06/03/filestream-3/

    https://blogs.msdn.microsoft.com/alexejs/2009/06/09/563/

    Nosql быстрее реляционной SQL.

    https://xakep.ru/2014/01/11/nosql-bd-test/

    https://cyberleninka.ru/article/v/sravnitelnyy-analiz-proizvoditelnosti-sql-i-nosql-subd

    А вот пример на инфостарте для CouchDB . Наверное видел его?

    https://infostart.ru/public/139279/

    Reply
  7. Silenser

    (6)

    Кажется запись больших файлов в MSSQL, используя FileStream быстрее чем обычной записи.

    Вот в тему публикация на инфостарте: https://infostart.ru/public/538764/

    Видел эту публикацию. Интересно, но нужна ВК, чтобы проверить. Хотелось бы, конечно, через COM.

    (6)

    Nosql быстрее реляционной SQL

    Для задачи хранения файлов — да, т.к. по сути NoSQL это структура, содержащая структуры и т.д. Выборка будет быстрой, но эти базы для того изначально и предназначены. В задачах, связанных с транзакциями, они будут проигрывать.

    (6)

    А вот пример на инфостарте для CouchDB . Наверное видел его?

    https://infostart.ru/public/139279/

    Видел, решил не повторяться.

    (6)

    Другие рассуждения об этом:

    А вот это интересно, почитаем, спасибо.

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *